MedMantra Software Requirements Specifications ver.0.1
Med Mantra
Patient Relationship ManagementSoftware Requirements Specifications
Version 0.3
July 20, 2013
Internal Use Only i
MedMantra Software Requirements Specifications ver.0.1
DOCUMENT RELEASE NOTICE
Document Details:
Name Version No.
Description Date
Software Requirements Specifications
0.1 SRS document for Med Mantra, Patient Relationship Management of Apollo Hospitals
11.08.2011
Software Requirements Specifications
0.2 SRS document for Med Mantra, Patient Relationship Management of Apollo Hospitals
28.09.2011
Software Requirements Specifications
0.3 SRS document for Med Mantra, Patient Relationship Management of Apollo Hospitals
20.07.2013
Revision Details
Internal Use Only ii
MedMantra Software Requirements Specifications ver.0.1
Internal Use Only iii
MedMantra Software Requirements Specifications ver.0.1
Action taken(Add/Del/Change)
Preceding Page No.
New Page No.
Revision Description
Feedback, complaints, Billing etc. to be linked to UHID /In-patient number
101 101 UHID & Patient Identifier No. also included
Enquiry Form 60 60 Customer name & caller name , secretary name included
Doctors In & Out time 15 16 Remarks to be included in the reminder dashboard
Post visit follow up 50 50 Nearest pharmacy URL addedCounseling 119 119 Referral NGO list added for
financial assistance .Health club label changed to Support Group
International patient management
204 204 HCF , FRRO details added.
International patient management
Referral organization, treating physician added to the pre arrival dashboard
Feedback management
104 104 Multiple sources of capturing the feedback
Appointment Reminder & Enquiry
22 22 Mobile search option required on the work list page.
Appointment Reminder & Enquiry
22 22 Filter by Preferred date required in appointment reminder page
Enquiry dashboard 65 65 PRN generation link required in the Enquiry dashboard
Feedback Management
109 109 Post visit Ip patients feedback to be part of the feedback worklist
This document and any revised pages are subject to document control. Please keep them up-to-date using the release notices from the distributor of the document.
Approved by: Date:
Authorized by: Date:
Internal Use Only iv
MedMantra Software Requirements Specifications ver.0.1
TABLE OF CONTENTS
1. INTRODUCTION.................................................................................................................. 11.1 PURPOSE......................................................................................................................... 11.2 SCOPE............................................................................................................................. 11.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS..................................................................2
2. GENERAL REQUIREMENTS..............................................................................................32.1 OVERVIEW....................................................................................................................... 32.2 INTERRELATION OF MODULES............................................................................................4
2.2.1 Table of Inter- Module Interactions..........................................................................52.3 COMMON / GENERIC BUSINESS RULES..............................................................................7
3. SPECIFIC REQUIREMENTS...............................................................................................83.1 REMINDER/FOLLOW UP ACTIVITIES.....................................................................................8
3.1.1 Navigation Chart......................................................................................................83.1.2 Screen Layout : <Reminder/Follow up DashBoard>...............................................83.1.3 Common/Generic Business rules for Follow up activities........................................93.1.4 Appointment Follow up/Reminder.........................................................................13 ...................................................................................................................................... 173.1.5 Appointment Module Alerts......................................................................................33.1.6 Follow up of No-Show patients................................................................................93.1.7 Follow –Up of Blood Donors..................................................................................143.1.8 Post Visit Follow-Up...............................................................................................203.1.9 Enquiry Dashboard................................................................................................303.1.10 Information Dashborad........................................................................................50
3.2 FEEDBACK & COMPLAINT MANAGEMENT..............................................................643.2.1 Business Process details.......................................................................................643.2.2 CAPTURING FEEDBACK......................................................................................703.2.3 Feedback managment...........................................................................................743.2.4 Action on Feedback...............................................................................................773.2.5 Review of Action taken on Complaint....................................................................793.2.6 SEND APPROPRIATE COMMUNICATION TO THE CUSTOMER ......................823.2.7 Input Attributes.......................................................................................................843.2.8 Complaint Monitoring sheet...................................................................................85
3.3 COUNSELING .................................................................................................................863.3.1 Business Process Details......................................................................................883.3.2 Blood Donor Counseling........................................................................................943.3.3 Counseling the grief .............................................................................................98
3.4 DISEASE MANAGEMENT PROGRAM................................................................................1013.4.1 Business Process Details.....................................................................................103
3.5 PROGRAMME MANAGEMENT..........................................................................................1073.5.1 Program Management Set up..............................................................................1073.5.2 ADD CUSTOMER TO THE PROGRAMME.........................................................1113.5.3 Program Owner Work List....................................................................................114
3.6 CUSTOMER LOYALTY PROGRAMME................................................................................1183.6.1 Define the Programme.........................................................................................1213.6.2 REGISTER CUSTOMERS IN LOYALTY PROGRAMME....................................1233.6.3 Define Earning Point:...........................................................................................1253.6.4 Define business rule for burning points................................................................1263.6.5 Map Rules to loyalty program process.................................................................1273.6.6 Have audit trail for each point earned and burnt..................................................129
3.7 PATIENT PREFERENCE CARD.........................................................................................1303.7.1 Business process.................................................................................................131
3.8 PATIENT ACTIVITY CHECK LIST......................................................................................1343.8.1 Business Process................................................................................................135
3.11 E-REFERRALS ............................................................................................................1363.11.1 General Business Process Details....................................................................1363.11.2 Registration of Refferal doctor..........................................................................140
Internal Use Only v
MedMantra Software Requirements Specifications ver.0.1
3.11.3 Receive Referral Request ................................................................................1423.11.4 Follow up of referral patients By Call centre.......................................................1453.11.5 Manage Refferals...............................................................................................1483.11.6 Refferal Desk ....................................................................................................151
3.12 STAFF FEEDBACK ON THE PATIENT...................................................................1533.12.1 Business Process detail.....................................................................................1533.12.2 Create Staff Feedback.......................................................................................1553.12.3 View Staff Feedback ........................................................................................156
3.13 VIRTUAL CONSULTATION............................................................................................1573.13.1 Request for Virtual consultation.........................................................................1573.13.2 Steps for Virtual consultation using Skype in Med mantra application..............159
3.14 ENABLING EXTERNAL ENTITIES....................................................................................1623.14.1 Business process details....................................................................................162
3.15 HEALTH TIPS & BIRTHDAY /ANNIVERSARY WISHES.......................................................1653.15.1 Business Process..............................................................................................1653.15.2 Select Target Audience ADD MEMBERS..........................................................1673.15.3 Create Message & SEND.................................................................................1683.15.4 Reports.............................................................................................................169
3.16 INTERNATIONAL PATIENT MANAGEMENT .....................................................................1693.16.1 Business process Description............................................................................1693.16.2 Patient Work list................................................................................................1723.16.3 Create IPS ID.....................................................................................................1763.16.4 Request form....................................................................................................1793.16.5 Follow up of International Patients....................................................................1813.16.6 Complete details................................................................................................1843.16.7 Post visit follow up.............................................................................................1883.16.8 Arrival Record....................................................................................................190
3.17 CONSTRAINTS AND LIMITATIONS.................................................................................1923.18 REPORTS................................................................................................................. 1923.17 USER ROLES MATRIX.................................................................................................1953.18 ASSUMPTIONS AND DEPENDANCIES.............................................................................1963.19 INTERFACE / INTEGRATION NEEDS...............................................................................196A. EXTERNAL APPLICATION INTERFACES .............................................................................196B. EQUIPMENT/DEVICE INTERFACES ....................................................................................1973.20 PERFORMANCE REQUIREMENTS..................................................................................1973.21 LOGICAL DATABASE REQUIREMENTS...........................................................................1973.22 DESIGN CONSTRAINTS................................................................................................197
Total Number of pages: 229
Internal Use Only vi
MedMantra Software Requirements Specifications ver.0.1
1. Introduction
1.1 Purpose
The main purpose of this document is to detail the PRM activities and functions. To get approval from the users and this SRS acts as input to the next phase of development. This document describes about the Patient Relationship Management (PRM) – CRM. The activities and the business processes are explained in this SRS
1.2 ScopePatient Relationship Management (PRM) module deals with the various aspects of maintaining an ongoing relationship with existing and new patients, hence, providing a personalized service. It also includes addressing patient complaints and concerns and putting in place a process to ensure complaints don’t recur.
Support Systems that enable e-mail-based communications, automate follow-up activities like appointment scheduling and information sharing, and integrate processes across organizations can help with care coordination.
All Activities which would increase the patient satisfaction as well enhance their experience
PRM users of the hospital should be able to do the following activities:-
Reminder/follow up activitieso Appointment Follow Upo No show appointment follow upo Post OP/IP Visit follow up including feedbacko Blood donor follow up
Enquiry dashboard Feedback & complaint management Staff feedback about the patient Programme management – Programmes run to personalized
programmes for previlized customers Loyalty programme management Disease management programmes for chronic illness Birthday/Anniversary wishes Sending Health tips to target audience Counseling e-Referral International patient Management Enabling External entities – Remote health monitoring, Telemedicine
etc Virtual consultation Doctors collbration & CME ‘s
Internal Use Only 1
MedMantra Software Requirements Specifications ver.0.1
1.3 Definitions, Acronyms and AbbreviationsTerm DefinitionAHC Apollo Health CheckupCRM Customer Relationship Management CVD Cardio Vascular DiseaseDMP Disease Management ProgramHL7 Health Level 7IP In-PatientMIS Management Information SystemOPD Out-Patient DepartmentOT Operation TheaterPRM Patient Relationship ManagementRFID Radio Frequency IdentifierSMS Short Message ServiceUHID Universal Health Identifier HIPAA Health Insurance Portability and Accountability Act of 1996
Abbreviation/Acronym DescriptionIPS International Patient services departmentHOD Head of the DepartmentCME Continuous Medical EducationVIP Very Important personCEO Chief Executive OfficerE-Mail Electronic MailICU Intensive Care UnitFRRO Foreign regional registration office
Internal Use Only 2
MedMantra Software Requirements Specifications ver.0.1
2. General Requirements
2.1 OverviewPatient Relationship Management (PRM) module deals with the various aspects of maintaining an ongoing relationship with existing and new patients including international patients, hence, providing a personalized service. It also includes addressing patient complaints and concerns and putting in place a process to ensure complaints don’t recur.
Following are the activities done by the PRM users of the hospital
Reminder/follow up activitieso Appointment Follow Upo No show appointment follow upo Post OP/IP Visit follow up including feedbacko Blood donor follow up
Enquiry dashboard Feedback & complaint management Staff feedback about the patient Programme management – Programmes run to personalized
programmes for previlized customers Loyalty programme Birthday/Anniversary wishes Health tips – general, specific to a disease/risk factor Counseling dashboard e-Referral International patient dashboard Enabling External entities – Remote health monitoring, Telemedicine
etc Virtual consultation Doctors collbration & CME ‘s
Manage and track calls, emails and queries through other modes of communication Maintain patient details and preferences Provide pre-visit information to the patient Follow up with patients regarding their visit through different modes of communication Provide reminders to patients through different modes of communication Collect feedback from patients and visitors Take action on complaints, ensure concerned department takes corrective action and appraise
patient of the status of their complaint Counsel patients on various aspects of their visit/care Engage patients through long term contact programs Run disease management programs to help patients control their disease through
medication/lifestyle change and other interventions Run loyalty programs which track usage of hospital services and reward patients for their
loyalty towards the hospital/group Providing virtual consultation & remote health monitoring benifiting people /patients out of
reach also. Promoting Doctors collabration in care plan & treatment
Internal Use Only 3
MedMantra Software Requirements Specifications ver.0.1
2.2 Interrelation of Modules
Internal Use Only 4
MedMantra Software Requirements Specifications ver.0.1
2.2.1 Table of Inter- Module InteractionsS. No.
Message Code
Message Name
From Sub process Code
To Sub process Code
Attributes Expected Response
Message Compliance (HL7, etc..)
1 Patient Demographic Details
Registration PRM NameAgeAddressOccupation
2 Patient category type
Registration PRM (AHC type/OP/IP)
3 Referral cases
Registration PRM Referral Dr. Name
Only referral doctor name
4 VIP/CEO’s registration
Registration PRM Name, Company Name,
5 Status of patient
Patient Record
PRM Patient Status
6 Chronic disease patients details
Patient Record
PRM Chronic disease name, Patient
details from registration
7 VIP/CEO’s admission
A&T PRM Name, Company Name,IP No., Bed No
8 Patient discharge Status
Wards & Discharge
PRM Discharge status
9 Dept. HOD details,
Employee name
HR PRM Department HOD name,
Email, Contact No, Employee
name
For sending reports to HOD’s of
Departments & Employee
name for complaints
10 Appointment details
Appointment & Scheduling
PRM Appointment date, place, time, Doctor
Name11 Appointment
cancelled alert
Appointment & Scheduling
PRM Patient name,
contact info, appointment
info12 Fixing/Re-
scheduling appointment
PRM Appointment &
Scheduling
Patient name,
contact info, appointment
Internal Use Only 5
MedMantra Software Requirements Specifications ver.0.1
info13 Health
check-up record of patient
AHC PRM Report When patient enquires about his health check-up report
14. Patient Details
Emergency PRM When patient is
admitted in Emergency, an alert is
received to the PRM
15. Referral doctor details
Marketing PRM Ref. Dr. Name,Contact info.
16. Wellness analysis report
PRM Marketing Corporate name,
Health risk of
employees17. Prescription
details Pharmacy PRM Medicine
cost, medicine
details
Prescription details of the patients who
has not taken the medicine
18. Blood donor details
Blood Bank PRM Blood donor details
Follow-up of blood
donors19. Blood donor
detailsBlood Bank PRM Blood donor
details,Sero-
positive details
To counsel the sero-positive donor
20. Billing details Billing PRM Billing details
21. Feedback PRM Dept Feedback reports
22. Complaints PRM Dept Complaint status, action
description23. Employee
DetailsHR PRM Employee
name, IDWhen
complaint is made
against the employee
then employee
details must be auto
populated
Internal Use Only 6
MedMantra Software Requirements Specifications ver.0.1
24. Package details
AHC PRM Package, tariff, time required to undergo package
25. Tariff details of a corporate
Quote Management
PRM Services, tariff
26. Corporate details
Marketing PRM Corporate name, contact person, contact number
27. Pre-requisite information
Billing /Help Desk
PRM Pre-requisite information
2.3 Common / Generic Business Rules
Intimating the Referral Doctor about the patient visit to the hospital is done through preferred mode of contact (Telephone/Mail/E-Mail/SMS/Fax) and the frequency should be customizable.
When next Date & Time to call is entered, the PRM should get an auto-generated reminder for follow-up of patient.
If Call Status is ‘Not interested’ to receive calls then PRM should not get the patient record for follow-up.
Automatic SMS/ Email reminders for appointment , scheduled visits, birthday & anniversary wishes
Health tips for target audience through SMS or E-Mail.
Internal Use Only 7
MedMantra Software Requirements Specifications ver.0.1
3. Specific Requirements
3.1 Reminder/Follow up activitiesUser Interface to include the following activities of Reminders, PRM Users are involved in activities of reminding &/ following up with the patient for various purposes. Thier activities include
Include Appointment Follow up No show follow up Post Visit follow up
o Prescription Follow up Blood donor Follow up Enquiry Follow up
3.1.1 Navigation Chart
3.1.2 Screen Layout : <Reminder/Follow up DashBoard>
Tentative screenLayout.
Internal Use Only 8
PRM Call centre activities Reminder/follow up activities
MedMantra Software Requirements Specifications ver.0.1
3.1.3 Common/Generic Business rules for Follow up activities
The system should manage:1. Reminder call time lines – before how many hours/days the call will be given, therefore
preparing the day’s task for the executive/s.2. Call load management – task distribution among the executive online for the reminding
function.3. Delisting the reminding task from the work list once it is attained by a caller.4. Giving options to earmark the not contacted/ from contacted list.5. During the call the caller should be able to provide different communication details via
SMS, EMAIL etc.6. Day end closure call list which shows the pending calls which were not completed for
the particular date7. Caller wise day End /shift wise reports Total Login time, No. of calls taken per activity,
minimum No. of calls for that activity. 8. Report on callers who have not met the minimum calls (as defined)per activity per shift
&/ day 9. Configuration at centre level (regional/centre level) to select static (Non distribution) or
dynamic call distribution method while generating work list. Also the minimum & maximum calls per activity & day should be configurable
10. Contact/Call centre defined Employees mapped against each contact/call centre
Should have separate link of day end closure call list – All pending calls/reminders for that day have to displayed. This list can be populated based on business rule which will define the cut off time which would be taken as basis for generating the pending list for that day.
Provision to differentiate high priority items through some mechanism (sort/ color code etc ) Such as call u back status calls/ waitlist to confirmed call follow ups
During the reminder call user should be able to reschedule/cancel the appointments
Business Rules for Work list creation
Call center creation: System should allow the user to create call centers and map the all the regional center or the
intra regions to the call center to handle the call. Against each call center all the executives to be mapped so that appointments reminder comes
to the executive for follow up. System should allow the user to declare or sign in for the reminder activity. System keeps track of the number of users login at a particular time to handle the reminder call
and therefore distribute the call with the below logic.
System should allow the user to set the time for the reminder call say on previous day / before x hour of the appointment each customer will get the reminder call.
The system should able to manage the rule for non working days of the call center. Say all appointments of Monday will be reminded on Saturday.i.e Non working day work list will fall into previous working day/s
Work list can be segregated into Appointment follow-up/reminders No Show follow ups Post visit OP/IP patient follow up Blood bank donor follow up Enquiries
Hence system is able to find the total number of calls to be made on a particular day and time.
Internal Use Only 9
MedMantra Software Requirements Specifications ver.0.1
The system should have the capability to assign the reminder call list as per the following logic to manage the call loads among the call center executive deployed to manage the reminder calls.
The work list for an individual employee will depend: Each call can be closed with status: Reminded (closed from the work list)/ Call me back
(With date and time)- to appear again before T time (Set up required).Any other status as required by the business to maintained as part of LOV( when caller doesn’t even receive the call etc)
If any logger working on a work list item then it should not allow any other logger to perform any activity on that item till the first logger completes that activity.
In dynamic method of call distribution If one person logged in, the entire work list to be loaded to him If second person logs in then it equally distributes if minimum no. is met by first
logger as per set up, else current logger does not get any item. Any executive logs out, his/her entire list is distributed to make the load equal.
It first fills if somebody is having less than minimum, then checks who has got least no. of load in the queue and adds to the next highest. Process continued till equal load distribution..
Minimum call X nos. & maximum calls for an individual employee On particular login into the appointment follow up dashboard the user should have
option to start working on the work list. Restricting the Work load/ work list items of a particular individual will be restricted
based on the call volume for that particular day & No. of employees logged in currently. If the particular user who has attended the call earlier is Logged in then the work list
item goes to that particular employee . In his absence the work list item is distributed to others
The HOD of call centre to view all the information per Shift/Day at a glance The No. of reminder activities & enquiries received on a particular day Total no. of employee Logged in & Logged out per shift/day
Business Rules for Reminders Informing Referral Doctor about the patient through Phone/mail/SMS, the frequency of reminder should be customizable .e.g. like for every patient wise on a daily or weekly or monthly basis. Type of follow up
Appointment reminder No show follow up Post/pre visit follow up Blood donor follow up
Reminder required
Appointments Yes Before x days /y hours of scheduled appointment The number of days for the reminder for waitlist to confirmed appointment work list should be configurable (for e.g. send an SMS 3 days before appointment or call 1 day before the appointment)
Telephone – X daysMail – X daysSMS – X daysEmail - X days
Fax - X days The number of days for the reminder for all other appointments confirmed , rescheduled/ cancelled (except the waitlist to confirmed appointment list)should be configurable (for e.g. send an SMS 3 days before appointment or call 1 day before the appointment)
Internal Use Only 10
MedMantra Software Requirements Specifications ver.0.1
Telephone – X daysMail – X daysSMS – X daysEmail - X days
Fax - X days
Reminder required
No show yesAfter x days /y hours of scheduled appointment
The number of days for the follow up of all other No Show appointments should be configurable (for e.g. send an SMS 3 days before appointment or call 1 day before the appointment)
Telephone – X daysMail – X daysSMS – X days
Reminder required
Post visit follow up OP/IP yes
After x days /y hours of scheduled appointment
The number of days for the post visit follow up of all Op/IP visit should be configurable (for e.g. send an E-mail 1 days after visit or call 1 day after the appointment)
Telephone – X daysMail – X days
SMS – X days Frequency of the reports should be customizable i.e. hourly/daily/alternate/weekly
Reminder required
Blood Donors yesAfter x days /y hours of Blood donation
Work list closure- when call status is not interested or call closed(call closed -except for blood donor follow up) . Work list closed & removed from the call list
Doctors calender if blocked / slot is been held then the information to be depicted/highlighted in PRM –appointment reminder dashboard
Doctor in & out time to be updated as when the user recieves information & perform action based on the remarks.
Internal Use Only 11
MedMantra Software Requirements Specifications ver.0.1
Pre- requisite nformation assocoiated with the service ID should be viewable by the PRM user
SMS alert 5 days prior about the next Health check-up of customer from the Patient Record/AHC module.
Internal Use Only 12
MedMantra Software Requirements Specifications ver.0.1
3.1.4 Appointment Follow up/Reminder
3.1.4.1 OP Appointment Follow up/reminder
Figure 2 : Appointment Reminder Flow diagram
Internal Use Only 13
MedMantra Software Requirements Specifications ver.0.1
3.1.4.1.1 Business Process Details
Internal Use Only 14
Description
After appointment is booked business follow up the patient to remind the customer about his/her scheduled engagement with a doctor or any service provider of the hospital. Apollo Hospitals being group hospitals having multiple branches across the country, the business require having a managed work list to follow up the customers. During the reminder call the customer may ask to reschedule or cancel or confirm his willingness to visit the hospital, hence the process should enable the user to register such requests.
All calls to the callcentre if IVR based then system integration required to generate the worklist based on the IVR call transaction.(if required)
The system should have two work list to interact or follow up with customers:
Confirmed appointments follow up (As per the follow up set up rules)
Waitlist appointment confirmed (as and when the waitlist is confirmed)
In Apollo there are multiple source of booking an appointment like Direct booking through call center Web based booking – EDOC Wellness center appointment Clinical trial appointments Disease management programme appointments Post IP visit follow up Post OP visit follow up
Hence system should be able to provide an mechanism to integrate all such source of appointment to provide a common reminder work list (TBD)
However the system should manage( refer to common generic rules for reminder activity)
Users with access control
PRM- Executive
Pre – requisites
Appointment with confirmed status The appointments fall under the follow up set up criteria Confirmation of waitlisted appointments
MedMantra Software Requirements Specifications ver.0.1
Business Process Details
Process Description
Some patients take prior appointment for Doctor consultation or other hospital services.
PRM users gets the work list of all patients whose appointment is booked from various sources (whose mode of communication is Telephone/Mail) and appointment due date is in the next x days. (Refer to the BR)
PRM users gets the following details of the patient Appointment in the work list from the Registration, Appointments & CRM(Marketing) module
o Patient Name
o Contact Number(s)/other contact details
o Appointment Date & time
o Appointment type
o Preferred contact time and mode
o Referral Doctor Name
o Referral Doctor Contact information
Work list for appointment follow up will be shown two grids
All appointments which have been converted from waitlist to confirmed status
All other confirmed appointments from different source
Should have separate link of day end closure call list – All pending calls/reminders for that day have to displayed. This list can be populated based on business rule which will define the cut off time which would be taken as basis for generating the pending list for that day.
Provision to differentiate high priority items through some mechanism (sort/ color code etc ) Such as call u back status calls/ waitlist to confirmed call follow ups
During the reminder call user should be able to reschedule/cancel the appointments
During the call user should be able to send the details of the appointment through SMS, eMail ,mail etc.Business Rules for Work list creation( refer to common genric rules for reminder activity)
System should allow the user to set the time for the reminder call say on previous day / before x hour of the appointment each customer will get the reminder call.
The system should able to manage the rule for non working days of the call center. Say all appointments of Monday will be reminded on Saturday.
Work list can be segregated into Appointment follow-up/reminders No Show follow ups Post visit OP/IP patient follow up Blood donor follow up
Hence system is able to find the total number of calls to be made on a particular day and time.
The system should have the capability to assign the reminder call list as per the following logic to manage the call loads among the call center executive deployed to manage the reminder calls.(refer to coomon genric rules for reminder worklist )
.Note: system only sends the items only to the members eligible for that center not to
Internal Use Only 15
MedMantra Software Requirements Specifications ver.0.1
other executives.
The usage of the functionality shall be sending reminders to the patients scheduled for various services before a predefined period of time.
Objectives would be to Manage and track calls, emails and book & follow up appointments
(through other modes of communication also) Maintain patient details and preferences Provide pre-visit information to the patient Follow up with patients regarding their visit through different modes
of communication.
The work list dashboard will have following attributes
o Appointment ID- Appointment Id is created while booking an appointment in ES module/ Booked through E-DOC/ Wellness/ DMP etc
o Repeat appointment ID- If any repeat appointment taken against appointment ID the all previous appointment details to be populated with details like date of appointment, episode no, episode details etc.
o Source of appointment – E-doc/ ES/ wellness etco PRN No. or UHID Number- Generated while booking an
appointment. Option to convert PRN into UHID should be available.
o Patient Name o Patient Type – Cash or credit patient information can from
billing. Credit patients are requested to bring necessary documents while coming to the hospital for the appointment ( ID cards etc)
o Resource Name- Doctor name/ equipment Name etc details captured while booking an appointment
o Service name – Whether it is OP consultation/ clinical trail consultation/ investigation etc
o Department /specialty- As in appointment bookingo Date of appointment- Appointment date as in appointment
booking screeno Location – Hospital location at which appointment is bookedo Call status- As updated by PRM user during follow up.
Values can be Open, pending, closed, not interested, call u later etc
o Next follow up date & time- As updated by PRM user during follow up If the next follow up date & time is given by the
o Remarks- During follow up any remarks were captured by the PRM user
o Appointment status- Rescheduled/ confirmed/checked in /checked out etc
o Mobile search option required in the Enquiry dashboardo Prefferd date sort option /Filter by prefferd date option is
required in appointment reminder page
Provision to view call history will be available- caller details, date& time & remarks if any
Provision to view previous services details episode wise - ( Episode No, service available& status)
PRM users gather the patient pre-requisites information from the help desk. Call history/episode history/patient appointment details/referral doctor
Internal Use Only 16
MedMantra Software Requirements Specifications ver.0.1
details/pre requisites can be presented POP Up window where at a glance PRM user can view all the details & work upon by following up the patient & update the appointment status &/ call status accordingly.
Preferred mode of contact & time to be captured – Helps in contacting the patient /customer in his preferred time & mode.
Facility to mark the leave /breakdown of any resources should available . – Leave to be marked which will highlight all appointments against that resource so that alternative action to be taken on appointment as the resource will not available in the appointment given time.
The mode of sending reminders can be various media including, SMS, Telephone calls and emails.
PRM users call the Patient/Attendant and inform about the appointment, find out the patient’s existing UHID or help the patient generate a PRN. If an email reminder is sent a link to a pre-registration form should be included. This pre-registration form should generate a PRN for the patient.
If patient is willing to come to the hospital at the fixed appointment time, then the following information is passed on to the patient
o Pre-requisites before visiting the hospital
o Appointment Date & time
o Location
o Contact person to meet
If patient wants to re-schedule, PRM user’s access appointment module and appointment is scheduled according to availability of resources and patients preference.
Patient is instructed to bring the ID card (working organization) for Identity (In case of Corporate)
If the referral doctor refers patient, then PRM communicate (phone/email/mail) the patient appointment information to the referral doctor.
PRM Users updates the Call status. (Values can be Open, pending, closed, not interested, call u later etc)
PRM user should also be able to see the appointment status – checked/checked out etc.
If patient wants to remind after some period, then the Next Date Time to call is fixed and automatic alert is received to the PRM for reminding the patient.
The Remarks column is filled when the patient is not interested to receive calls in future or when the PRM users not able to contact the patient.
SMS: Step 1: All the patients with mobile numbers captured during the
registration detail capture would be sent Reminder SMS. Step 2: A setup for defining a predefined text with dynamic elements
of patient/doctor/appointment/facility details per location Step 3: Sending out the SMS during business hours and alerts for
non-delivered messages. Step 4: Patient can reply to the message confirming the appointment
or asking for it to be rescheduled.
Email: Similar process as SMS.
Business Rules for Reminders( appoint reminder BR to be reffered from common Internal Use Only 17
MedMantra Software Requirements Specifications ver.0.1
generic rules for reminding)
Frequency of the reports should be customizable i.e. hourly/daily/alternate/weekly
If patient is not a registered patient of the hospital, option should be given to patient to generate PRN and the patient is asked to come to the hospital 15 minutes before their appointment time.
HIPAA: A covered entity also may leave a message with a family member or other person who answers the phone when the patient is not home. The Privacy Rule permits covered entities to disclose limited information to family members, friends, or other persons regarding an individual’s care, even when the individual is not present. However, covered entities should use professional judgment to assure that such disclosures are in the best interest of the individual and limit the information disclosed. See 45 CFR 164.510(b)(3).
Alternate / Flexibility Options in the Business Process
Patient can be reminded more than once, when he/she asks to remind.
Outputs Patient is reminded about the appointment. The following reports are generated
o Call volumes day wise/Monthly/ yearly
o Follow up type wise reports on how many rescheduled/cancelled/No show patient were followed up.
o Periodic Call status wise reports
o Call volumes as per day end closure call list
o List of confirmed patients to visit the hospital on appointment date.
o List of appointments Re-scheduled patients.
o List of appointment cancelled patients.
o List of patients who asked to call later.
o Caller wise reports on total logged in hours,
Messages SMS will be sent to the patients about the appointment.Exception handling
-NA-
Error Reporting
-NA-
Scheduling The Scheduler sends a prior report on the patients who took appointment.The Appointment is cancelled/re-scheduled by accessing the Scheduler.The patient is called later when the patient is not available or asked to call later.
Trigger In The Scheduler sends a prior report on the patients who took appointment.
Trigger Out
The Appointment may be re-scheduled.
Assumptions
Appointment is already taken and patient contact information is available.
Internal Use Only 18
MedMantra Software Requirements Specifications ver.0.1
3.1.4.1.2 Reports - OP Appointment follow up/ReminderReport Description
Patient is reminded about the appointment. The following reports are generated o Call volumes day wise/Monthly/ yearly
o Caller wise call volumes day wise/monthly/yearly
o Follow up type wise reports on how many rescheduled/cancelled/No show patient were followed up. o Periodic Call status wise reports
o Call volumes as per day end closure call list
o List of confirmed patients to visit the hospital on appointment date.
o List of appointments Re-scheduled patients.
o List of appointment cancelled patients.
o List of patients who asked to call later
o Caller wise periodic reports on total logged in hours, total no of calls made , activity wise did not met minimum calls .o Total centre wise periodic reports on total logged in hours, total no of calls made , activity wise did not met minimum calls .o Total centre wise periodic reports on day end pending call volumes.
Internal Use Only 19
Sr. Request Request Name Time Action Require
Alert Notify Notify Mechanis
Remarks
1 PRM01 Appointment Reminders
Basing on the business rule
SMS should be sent to the patient
Appointment Details
Patient SMS/Email
The Reminder Postcard Process
MedMantra Software Requirements Specifications ver.0.1
3.1.4.2 Wellness appointment
Figure 3: Wellness Appointment Follow up
3.1.4.2.1 Business Process Details
Description
Wellness team captures the customers’ health information in the system who has undergone Health scan at the AHC (Apollo Health Check-up) and report is generated by the wellness system (existing). Counseling is done to the customer, based on the report.
Users with access control
PRM Users, Wellness Department users
Internal Use Only 20
MedMantra Software Requirements Specifications ver.0.1
Pre – requisites
Patient arrives at hospital.The customer arrives at the AHC for Health check up.
Business Process Details Process Description
The customer arrives at AHC (Apollo Health Check-Up). The Wellness gets report containing the data of customers who has
undergone Health scan from AHC. The Wellness team at the Health Scan captures the predefined
questionnaire from the customer and it is updated in the system. The Report is generated based on the questionnaires(configurable
location wise) and the logic provided to analyse the answers. The Report consists of analysis of risk of getting Cardiac, Kidney,
and Diabetic and Lung problem and any lifestyle modifications suggested. A print out of this report should be provided to the patient.
The counselor of Wellness at the Health Scan counsels the customer.& fills the questinaaire(configurable)
Based on questionnaire analysis(configurable) the analysis report is generated
If the analysis report consists of any risk prediction then counselor advises the customer to change life style and suggests the Yoga, Exercises, Diet habits.
Wellness team provides brochures & annexure to the customers. The wellness system is updated (with the counseling done and
provides precaution information to the customer).
Business Rules Existing wellness software should be integrated with the e-HIS.
The Wellness team should get the list of Health Scan (customizable) Customers from AHC.
While Wellness team updating the answer to the questionnaires the information already captured at Registration, EMR module should be auto populated.
For each patient who undergoes health scan and visits wellness center, revenue sharing happens in between Wellness center and Hospital, an X amount is shared to the Wellness authority.
The patient details & clinical details which are available in Registration, EMR should be auto populated basing on UHID. This feature should be included in the Wellness software
Alternate / Flexibility Options in the Business
-NA-
Internal Use Only 21
MedMantra Software Requirements Specifications ver.0.1
ProcessOutputs Reports are generated on
o List of customers who have undergone Health scan by corporate wise.
o List of customers who have undergone Health scan by corporate wise having a risk of health problem.
o List of customers by date wise.
o List of customer who has a risk of getting particular health problem.
Messages -NA-Exception handling
-NA-
Error Reporting
-NA-
Scheduling
-NA-
Trigger In Customer undergoes Health scan then an alert is received to the wellness customers
Trigger Out
-NA-
Assumptions
-NA-
3.1.4.2.2 Inputs/Attributes
Attribute Name Attribute DescriptionNature of
Data Element (MOC)
Conditions Logic
Data Type
Length / Size
List Of Values/Co
de Set
Originating Service/D
eviceRemarks
Patient UHID M 10 Registration
Title Title M Varchar 30 Registrat
ion
First Name Patients First Name M Varchar 50 Registrat
ion
Middle Name Patients Middle Name O Varchar 50 Registrat
ion
Last Name Patients Last Name M Varchar 50 Registrat
ionAppointment Date & Time Appointment Date & TimeM Date
Time Appointments
Preferred Mode of Contact
Mode of Contact preferred by the patient M Varc
har 50Mode of contact 08 Registration
Contact Number Contact Number of the patient C If preferred mode of
contact is telephoneNumber 15
Internal Use Only 22
MedMantra Software Requirements Specifications ver.0.1
Address Patients Address C
If preferred mode of
contact is snail mail
Varchar 100
Email ID
Email ID of patient C
If preferred mode of
contact is Email
Varchar 50
Questionnaire
75 questions need to be captured M Varc
har
75 questions needs to be captured
Risk Analysis Report
Report on health risks M Varchar 200
It is a report based on the Risk Analysis
Call Status Status of the Call M 50Call Status 13
Next Date Time to callFuture date to call the patient, when
the patient asks PRM to call after sometime
C If Call status is call laterDateTime
Remarks Remarks if any C
If Call status is not
interested, then
Remarks should be captured
200
Internal Use Only 23
MedMantra Software Requirements Specifications ver.0.1
3.1.4.2.3 Follow up of wellness Customers
Figure 4 : Follow-up of Wellness customers
Internal Use Only 24
MedMantra Software Requirements Specifications ver.0.1
3.1.4.2.4 Business Process DetailsDescription Wellness sends a report on the patients/customers who has to visit the hospital for
health check-up. PRM calls the patient/customer and informs about the next date of visit.
Users with access control
PRM Users, Wellness Department users
Pre – requisites The customer/patient has undergone Health check up.
Business Process Details Process Description
The Wellness gets an alert 5 days prior about the next Health check-up of customer from the Patient Record/AHC module.
The Wellness team calls/mails the customer about the next Health check-up.
If patient is not interested to come on the check-up date, then the status of the visit is changed to not interested/call later/pending/not confirmed/rejected.
When the customer undergoes next Health Scan, then the wellness team at the Health Scan captures the same questionnaire except static information.
The comparison report is generated from the previous and present Health Scan.
From the report the counselor counsels the patient and explains the steps to follow to overcome the health risks.
The Wellness team analyzes the reports of Health scan basing on corporate wise and the risk of getting a particular health problem is identified.
Business Rules The Wellness gets & sends an alert X days prior about the next Health check-
up to customer from the Patient Record/AHC module. An Auto generated Email to the customer about the next Health check-up
should be sent.
Alternate / Flexibility Options in the Business Process
-NA-
OutputsReports are generated on
o List of customers accepted to come on check-up date.
o List of customers rejected to come.
Messages -NA-Exception handling
-NA-
Error -NA-
Internal Use Only 25
MedMantra Software Requirements Specifications ver.0.1
ReportingScheduling -NA-Trigger In Gets the list of wellness customers for follow-up.Trigger Out -NA-Assumptions -NA-
3.1.4.2.5 Input Attributes
Attribute Name
Attribute Description
Nature of Data Element (MOC)
Data Type
Length / Size
List Of Values/Code Set
Originating Service/Device
Remarks
UHID Patient UHID M Varchar 10 Registration
Title Title M Varchar 30 Title 07 Registration
First Name
Patients First Name M Varchar 50 Registrati
on
Middle Name
Patients Middle Name
O Varchar 50 Registration
Last Name
Patients Last Name M Varchar 50 Registrati
on
Appointment Date & Time
Appointment Date & Time M DateTime Appointm
ents
Preferred Mode of Contact
Mode of Contact preferred by the patient
M Varchar 50Mode of contact 08
Registration
Contact Number
Contact Number of the patient
C Number 15
Address Patients Address C Varchar 100
Email ID
Email ID of patient C Varchar 50
Call Status
Status of the Call M Varchar 50
Call Status 13
Next Date to call
Future date to call the patient, when the patient asks PRM to call after
C DateTime
Internal Use Only 26
MedMantra Software Requirements Specifications ver.0.1
sometime
Remarks Remarks if any C Varchar 200
Internal Use Only 27
MedMantra Software Requirements Specifications ver.0.1
3.1.4.3 Follow up of Clinical trial Patient
Figure 5 : Follow-up of clinical trial patients
3.1.4.3.1 Business Process detailsDescription The follow-up of clinical patients who has to visit the hospital/clinic
Users with access control
PRM Users
Pre – requisites
Patient/Customer is undergoing clinical trial.PRM should get an alert about the visit of clinical trial patients
Business Process Details
Process Description
For Internal Use Page 1 of 232
MedMantra Software Requirements Specifications ver.0.1
PRM gets a report of all the clinical trial patients who has to visit the hospital.
The report contains the details of the clinical trial patient like
o Patient name
o Contact number
o Trial name
o Doctor incharge
o E-mail ID
o Date of visit
The patient is informed about the next visit date by the PRM.
Business Rules
The HIPAA Privacy Rule permits a covered doctor or hospital to disclose protected health information to a person or entity that will assist in notifying a patient’s family member of the patient’s location, general condition, or death. See 45 CFR 164.510(b)(1)(ii)
Alternate / Flexibility Options in the Business Process
NA
Outputs Patient is informed about the clinical trial date of visit.
Messages NAException handling
NA
Error Reporting
NA
Scheduling NATrigger In NATrigger Out NAAssumptions NA
For Internal Use Page 2 of 232
MedMantra Software Requirements Specifications ver.0.1
3.1.5 Appointment Module Alerts
3.1.5.1 Business Process DetailsDescription Appointment & Scheduler module sends emails/SMS to the patients automatically.Users with access controlPre – requisites
Appointment is scheduled
Business Process Details
Process DescriptionSMS Alerts & E-mails: An auto generated SMS/E-mail is sent to the patient, 2 days prior to the hospital
visit. This SMS/E-mail contains the brief details like
o Appointment date & timeo Pre-requisiteso Department nameo Locationo Contact person to meet
An Auto generated SMS/E-mail is sent to the patient, 3 days prior to the prescription refill date. It includes the details like Medicine cost, Nearest Pharmacy details …
An Auto generated E-mail/SMS is sent to the patient, whenever patient Appointment is cancelled. It includes the details like reason for cancellation, Appointment date & time.
An Auto generated SMS/E-mail is sent to the patient, 5 days prior to the AHC. It includes the details like next health check up due date & time,pre requisite,location & contact person to meet …
The PRM calls/mails the blood donor and appreciates for donating blood.(E-mail is sent automatically from the blood bank module)
(For Cancellation, Follow-ups, Prescription follow-up the same data is sent to the patient through SMS/Email. It is sent automatically from Appointments scheduling module)
Business Rules An auto generated SMS/E-mail is sent to the patient, 2(TBD) (customizable) days
prior to the hospital visit. For International Patients the Email should be sent before 15(TBD) (customizable)
days prior to visit the hospital.
Alternate / Flexibility Options in the Business Process
-NA-
Outputs -NA-
Messages -NA-
For Internal Use Page 3 of 232
MedMantra Software Requirements Specifications ver.0.1
Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 4 of 232
MedMantra Software Requirements Specifications ver.0.1
3.1.5.2 Intimating Appointment cancellations
Figure 6 : Intimating Appointment Cancellations
3.1.5.3 Business Process
Description An alert is sent to PRM from Appointments module, whenever an appointment is cancelled due to doctor’s absence or failure in equipment. PRM employee calls the patient/attendant and informs about the cancellation and
For Internal Use Page 5 of 232
MedMantra Software Requirements Specifications ver.0.1
tries to re-schedule the appointment.Users with access control
PRM Users – Read only except status updation and appointment module access
Pre – requisites
Patient takes the appointment.PRM gets the list of patients whose appointments are cancelled.
Business Process Details Process Description
PRM users get an alert from Appointments module, when the appointments are cancelled and report is generated with the following details
o Patient Nameo Contact Number o Appointment Date & timeo Appointment typeo Reason for cancellation
PRM calls the patient, informs the patient about the cancellation of the appointment along with the reason.
If the patient is interested for re-scheduling the appointment, then the appointment is re-scheduled by accessing appointments scheduling.
If the referral doctor refers patient, then PRM communicate (phone/email/mail) the patient appointment information to the referral doctor.
PRM Users updates the status of the appointment (re-scheduled), contacted and interested to receive future calls.
If patient wants to remind after some period, then the Re-schedule date & time to call is fixed and automatic alert is received to the PRM, to call the patient for fixing the appointment.
Similar alerts can be sent via SMS or email. Business Rules
The Remarks column is filled when the patient is not interested to receive calls in future or when the PRM users not able to contact the patient.
(SMS/Email is sent to the patient when the appointment is cancelled even by the patient)
(Pop-up should come to the PRM when the appointment is cancelled and follow that a report should be sent to the PRM from appointments module)
We provide an Appointment cancellation policy review so, that each patient who avails the service has to fill the form & abide to rules set by the organization.
Medical Appointment Cancellation Policy
For Internal Use Page 6 of 232
MedMantra Software Requirements Specifications ver.0.1
Alternate / Flexibility Options in the Business ProcessOutputs Appointment will be fixed based on the patient’s requirements.
Reports are generated on
o List of appointments cancelled by Doctor/Specialty wise.
o List of appointments re-scheduled.
Messages PRM user gets an alert when the appointment is cancelled from the hospital.
Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In Cancellation of appointment process triggers the Intimating the appointment cancellation
process.Trigger Out Appointment may be re-scheduled or cancelledAssumptions An appointment exists and has been cancelled.
3.1.5.4 Input Attributes
Attribute Name
Attribute Description
Conditions
Logic
Data
Type
Length /
Size
List Of Values/Code Set
Nature of Data Eleme
nt (MOC)
Default
Value
Complianc
e
Originating
Service/Device
Remarks
UHID Patient UHID Varchar 10 M Registratio
n
Title Title Varchar 30 Title 07 M Mr. Registratio
n
First Name Patients First Name Varc
har 50 O Registration
Middle Name
Patients Middle Name Varc
har 50 O Registration
Last Name Patients Last Name Varc
har 50 O Registration
Appointment Date & Time
Appointment Date & Time
DateTime
M Appointments
Preferred Mode of Contact
Mode of Contact preferred by the patient
Varchar 50 Mode of
contact 08 M
Telephone
Registration
Contact Number
Contact Number of the patient
If preferred mode of contact
is telephon
e
Number
15 C
For Internal Use Page 7 of 232
MedMantra Software Requirements Specifications ver.0.1
Address Patients Address
If preferred mode of contact is snail
Varchar 100 C
Ref. Dr. Name
Referral Doctor Name Varc
har 50 O
Ref. Dr. Mode of Contact
Referral Doctor communication channel preferred
If Referral Dr. is selected Varc
har
50 Mode of contact 08
C
Ref. Dr. Address
Referral Doctor Address
If preferred mode of contact is snail
Varchar 100 C
Ref. Dr. Contact Number
Referral Doctor contact number
If preferred mode of contact
is telephon
e
Number
50 C
Corporate Name
Patient Working Organization name
Varchar 50 O
Cancellation Reason
The reason for cancellation of appointment
Varchar
200
M
Call Status Status of the Call Varc
har 50 Call Status 13 M Op
en
Remarks Remarks if any
If Call status is
not interested, then
Remarks should
be captured
Varchar 200 C
Next Date Time to call
Future date to call the patient, when the patient asks PRM to call after sometime
If Call status is call later
or If patient is intereste
d in taking
appointment later
DateTime
C
Process Checklists
S. No
Check list
Code
Check list
Name
Description
Triggering Event
Check Items
Business Rules for Generation
For Internal Use Page 8 of 232
MedMantra Software Requirements Specifications ver.0.1
- NA -
Alerts / Reminders / Notifications
Sr. NoRequest Code Request Name Time LimitAction Required
Alert MessageNotify UserNotify mechanism
Remarks
1 Cancellation SMS
5 min SMS should be sent to the patient
Cancellation of appointment
Patient SMS SMS is sent for the patient whose appointment are cancelled
For Internal Use Page 9 of 232
MedMantra Software Requirements Specifications ver.0.1
3.1.6 Follow up of No-Show patients
Figure 7: No show Appointments Follow up
For Internal Use Page 10 of 232
MedMantra Software Requirements Specifications ver.0.1
3.1.6.1 Business ProcessDescription The follow up of no-show patients, the PRM team calls the patients who took
appointment and not turned.Users with access control
PRM Users
Pre – requisites
Patient takes the appointment.Patient is not turned-up on the appointment time.
Business Process Details
Process Description Patient is not turned-up on the appointment time. Mechanism to identify the no show patients – apart from those marked as no show
by the secretary.(TBD) PRM users get report of all the no-show patients from the Appointments module
daily. The report contains the details of the no-show patients from Registration &
Appointments module like
o Patient Name
o Contact number
o Appointment date & time
o Appointment type
PRM calls the No-show patients. PRM enquires the No-show patient about the reason for not turning up. PRM asks the No-show patient to take another appointment. If patient is interested in taking the appointment, user accesses the Appointment
module for scheduling the appointment on the patient preferred date. Confirms with the patient about the new appointment. If patient refuses another appointment, reason to be updated in the system. If the referral doctor refers patient, then PRM communicate (phone/email/mail) the
patient appointment information to the referral doctor. PRM updates the status of the appointment (accepted/rejected). No show - Mechanism to identify if patient check out does not happens & billed
(TBD)Business Rules for call centre creation, worklist creation & call distribution location wise ( refer to common generic rules for reminder activity)
PRM users should get report of all the no-show patients from the Appointments module .
No show List generated after 24 hours of scheduled appointment (No show marked if the patient did not turn up for the scheduled appointment)
E-mail is sent to the patient automatically .
Alternate / Flexibility Options in the Business
-NA-
For Internal Use Page 11 of 232
MedMantra Software Requirements Specifications ver.0.1
ProcessOutputs The no-show patient takes the appointment if he/she is interested.
Reports are generated ono Periodic reports on List of no-show patients who took appointment.
o List of no-show patients rejected to take appointment with reasons
o List of no-show patients who took repeat appointment/rescheduled appointment & reason for No show of previous.
Messages -NA-
Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In Work list created about no-show patients. Based Business rule
Trigger Out Appointment may be scheduled.Assumptions PRM sends a report, which consists of no-show patients.
3.1.6.2 Input Attributes
Attribute Name
Attribute Description
Nature of Data
Element (MOC)
Data Type
Length / Size
List Of Values/Code Set
Conditions Logic
Default
Value
Capture Method (T/TA/C/R/D/L/LB
L)
Operations
(I/D/U/Q)
Originating
Service/Device
UHID Patient UHID M Varchar 10 T Q Registration
Title Title M Varchar 30 Title 07 Mr. D Q Registration
First Name Patients First Name O Varchar 50 T Q Registration
Middle Name
Patients Middle Name O Varchar 50 T Q Registrati
on
Last Name Patients Last Name O Varchar 50 T Q Registration
Appointment Date & Time
Appointment Date & Time M Date
Time T U/Q Appointments
Preferred Mode of Contact
Mode of Contact preferred by the patient
M Varchar 50Mode of contact 08
Telephone D Q Registrati
on
Contact Number
Contact Number of the patient C Number 15
If preferred mode of
contact is telephone
T Q
Address Patients Address C Varchar 100
If preferred mode of
contact is snail mail
T Q
Department name
Department name to which Patient needs to contact
M Varchar 50 T Q
Department Address of M Varchar 100 T Q
For Internal Use Page 12 of 232
MedMantra Software Requirements Specifications ver.0.1
Location Address
Department to which patient needs to contact
Contact person to meet
Contact person name to which Patient needs to contact
M Varchar 50 T Q
Ref. Dr. Name
Referral Doctor Name O Varchar 50 T Q
Ref. Dr. Mode of Contact
Referral Doctor communication channel preferred C Varchar
50Mode of contact 08
If Referral Dr. is selected
Telephone D Q
Ref. Dr. Address
Referral Doctor Address C Varchar 100
If preferred mode of
contact is snail mail
T Q
Ref. Dr. Contact Number
Referral Doctor contact number C Number 50
If preferred mode of
contact is telephone
T Q
Corporate Name
Working Organization name O Varchar 50 T Q
Reason for No-show Reason for no-show O Varchar 100 TA I/D/U/Q
Appointment Status Appointment Status M Varchar 50
Appointment Status 12
Pending D U/Q
Call Status Status of the Call M Varchar 50 Call Status 13 Open D U/Q
Next Date Time to call
Future date to call the patient, when the patient asks PRM to call after sometime
C Date Time If Call status
is call later T I/D/U/Q
Remarks Remarks if any C Varchar 200
If Call status is not
interested, then
Remarks should be captured
TA I/D/U/Q
Process Checklists
S. No
Check list
Code
Check list
Name
Description
Triggering Event
Check Items
Business Rules for Generation
-NA-
Alerts / Reminders / Notifications Sr. NoRequest Code Request Name Time LimitAction
RequiredAlert MessageNotify UserNotify
mechanismRemarks
For Internal Use Page 13 of 232
MedMantra Software Requirements Specifications ver.0.1
-NA-
3.1.6.3 ReportsReport Description
Patient is reminded about the appointment. The following reports are generated o Call volumes day wise/Monthly/ yearly
o Caller wise call volumes day wise/monthly/yearly
o Follow up type wise reports on how many rescheduled/cancelled/No show patient were followed up. o Periodic Call status wise reports
o Call volumes as per day end closure call list
o List of confirmed patients to visit the hospital on appointment date.
o List of appointments Re-scheduled patients.
o List of appointment cancelled patientsList of patients who asked to call later
For Internal Use Page 14 of 232
MedMantra Software Requirements Specifications ver.0.1
3.1.7 Follow –Up of Blood Donors
The PRM/Call Management team gets the information about the Blood donors. PRM calls the donor and thanks for donating blood and enquires about the next blood donation.
Figure : Follow-up of Blood Donors
3.1.7.1 Business Process Details
Description The follow-up of Blood donorsUsers with access control
PRM Users, Blood Bank Users
Pre – requisites The donor donates blood to the hospital.
Business Process Details
Blood donor donates blood to the hospital and the information about the donor is captured at the Blood bank.
For Internal Use Page 15 of 232
MedMantra Software Requirements Specifications ver.0.1
PRM gets a report of all blood donors from the Blood Bank module who has donated the blood recently (1 or 2 days back - configurable)
The report contains the details of the donor from the Registration module & Blood bank module like
o Donor name
o Contact number
o E-mail ID
o Blood donation date
The PRM calls/mails the blood donor and appreciates for donating blood.(E-mail is sent automatically from the blood bank module)
The PRM gets another list of blood donors who had donated blood 3 months back (configurable).
PRM calls the donor and enquires about his interest in donating the blood. (E-mail is sent automatically from the blood bank module enquiring about donor’s interest in donating the blood in the future) If donor is interested in donating the blood, then PRM user access the Appointment
module and schedules the appointment on the donor preferred date. Alternatively – the next visit date can be selected from PRM itself. If donor is not interested in donating the blood, then PRM updates the donor
interest as rejected and captures reason.
Business Rules PRM gets a report of all blood donors from the Blood Bank module who has
donated the blood recently (1 or 2 days back) Thanks E-mail is sent automatically from the blood bank module Reminder E-mail is sent automatically from the blood bank module enquiring about
donor’s interest in donating the blood in the future. The PRM gets another list of blood donors who had donated blood 3 months back
(90-180days).
Alternate / Flexibility Options in the Business Process
-NA-
Outputs Blood Donor takes appointment if he is willing to donate blood.
Reports are generated on
o List of blood donors accepted to donate blood.
o List of blood donors rejected to donate blood.
For Internal Use Page 16 of 232
MedMantra Software Requirements Specifications ver.0.1
o List of blood donors who donated blood X number of times.
Messages Thanks E-mail is sent automatically from the blood bank module
Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-
Trigger In A worklist generated as per business rule defined (from Blood Bank module) to follow-up the blood donors.
Trigger Out -NA-Assumptions Blood donor details should be available in the report.
3.1.7.2 Input Attributes
Attribute Name
Attribut
e Description
Data Type
Length /
Size
List Of Values/Code Set
Nature of
Data
Element
(MOC)
Conditions Logic
Default Value
Capture
Method
(T/TA/C/R/D/L/LB
L)
Operations (I/D/U/Q)
Originatin
g Service/Devic
e
Remarks
UHID
Donor UHID
Varchar 10 M T Q
Registration
Title Title Varchar 30 Title
07 M Mr. D QRegistration
First Name
Donors First Name
Varchar 50 O T Q
Registration
Middle Name
Donors Middle Name
Varchar 50 O T Q
Registration
Last Name
Donors Last Name
Varchar 50 O T Q
Registration
Blood Group
Name of Blood Group
Varchar 50 M D Q
Blood Bank/Patient Record
Blood donation date
Recent Blo
DateTime M T Q
Blood Bank
For Internal Use Page 17 of 232
MedMantra Software Requirements Specifications ver.0.1
od donation date
/Patient Record
Appointment Date & Time
Appointment Date & Time
DateTime M T U/
Q
Appointments
Preferred Mode of Contact
Mode of Contact preferred by the Donor
Varchar 50
Mode of contact 08
M Telephone D Q
Registration
Contact Number
Contact Number of the Donor
Number 15 C
If preferre
d mode of contact is
telephone
T Q
Address
Donor Address
Varchar
100 C
If preferre
d mode of contact is
snail
T Q
Department Location Address
Address of Department to which Donor needs to contact
Varchar
150 M T Q
Contact person to meet
Contact pers
Varchar 50 M T Q
For Internal Use Page 18 of 232
MedMantra Software Requirements Specifications ver.0.1
on name to which Donor needs to contact
Corporate Name
Working Organization name
Varchar 50 O T Q
Blood Donation status
Blood donation status
Varchar 50
Blood donation Status 12
M Pending D U/
Q
Area(location)
Blood Bank Location nearest to the Donor
Varchar 50 C
Blood Donation Status is Confirmed
U/Q
Blood Bank Center
The Blood Bank center information is accessed from Other Blood banks
Center Code
Center code of Blood bank
Varchar 50 O
Auto population of center code basing on Area
Q
Blood Bank Center
Center Name
Blood
Varchar 50 O Aut
o Q Blood
For Internal Use Page 19 of 232
MedMantra Software Requirements Specifications ver.0.1
Bank Center Name
population of center name basing on Area
Bank Center
Call Status
Status of the Call
Varchar 50
Call Status 13
M Open D U/Q
Next Date to call
Future date to call the Donor, when the Donor asks PRM to call after sometime
DateTime C
If Call status is
call later
T
I/D/U/Q
Remarks
Remarks if any
Varchar
200 O TA
I/D/U/Q
Process Checklists
S. No
Check list
Code
Check list
Name
Description
Triggering Event
Check Items
Business Rules for Generation
-NA-
Alerts / Reminders / Notifications
Sr. NoRequest Code Request Name Time LimitAction Required
Alert MessageNotify UserNotify mechanism
Remarks
For Internal Use Page 20 of 232
MedMantra Software Requirements Specifications ver.0.1
-NA-
3.1.8 Post Visit Follow-Up The Post visit follow up is for those patients who have consulted the doctor or undergone treatment.
Figure 1 : Post Visit Follow-up
3.1.8.1 Business Process
Description The Post visit is the follow up of the patient after visiting the hospital.PRM contact the patients who are advised for a follow-up visit by doctors and fix an appointment for the follow-up visit. All patient who underwent a health check also need to
For Internal Use Page 21 of 232
MedMantra Software Requirements Specifications ver.0.1
be followed-up after 1 year.
Users with access control
PRM users
Pre – requisites
The patient must be a registered patient.The patient already visited the hospital for treatment/consultation /lab investigations/health check
Business Process Details
Process DescriptionPatient consults the doctor, undergoes treatment or takes Lab investigations and if required doctor may advise the patient to visit after some period.
PRM gets the list of patients from PATIENT RECORD in the worklist, which is advised by doctor to the patient for next visit.
Worklist contains both OP & IP patients list & next advised date of visit to the hospital/doctor (as per Op summary/Discharge summary).
For an patient the following follow up attributes are askedo Did they take the medicine prescribed by the doctor?
Yes- What it effective – Yes/NO If NO then did they visit any other doctor/hospital ? If the answer is yes for the above question then the place they
have visited has to be capturedo Is the patient willing to come to the hospital – Yes/NO
If yes then schedule the appointment If NO, update the call status as not interested.
o The report on patient not willing to visit on next advised date of visting the doctor goes to secretary of the doctor before x days of advised date of next visit
The worklist contains the following information from the Registration & patient record module
o Patient Nameo Contact Number
o Doctor Advised Date
o Other discharge advise/prescription given to patient
PRM calls the patient and checks whether patient is following the discharge advise/prescription. Also informs about the doctor’s advised date of visit.
If patient is willing to come on that follow up date, then user access Appointment module and fixes the appointment.
User must provide the pre-requisites information for the follow-up visit by accessing Help desk.
If patient wants to schedule the follow up appointment on a different date then the next follow-up date is updated in the Patient Record. User informs the patient prior to this new follow-up date.
If a referral doctor refers patient, then PRM communicate (phone/email/mail) the patient appointment information to the referral doctor.
PRM updates the system about the appointment. PRM Users updates the Call status. If patient wants to remind after some period, then the Next date to call is fixed and
automatic alert is received to the PRM for reminding the patient.
For Internal Use Page 22 of 232
MedMantra Software Requirements Specifications ver.0.1
The Remarks column is filled when the patient is not interested to receive calls in future or when the PRM users not able to contact the patient.
For patients who availed of health check a reminder call for another health check has to be made 1 year later.
Business Rules An alert/report is sent to the PRM from Patient Record module, at a fixed time
(customizable attribute) prior to the doctor’s advised date to the patient. If patient wants to remind after some period, then the next date to call is fixed and
automatic alert is received to the PRM for reminding the patient. The Remarks column is filled when the patient is not interested to receive calls in
future or when the PRM users not able to contact the patient. An auto generated SMS is sent to the patient after fixing the appointment from
appointments module. The report on patient not willing to visit on next advised date of visting the doctor
goes to secretary of the doctor before x days of advised date of next visit
Alternate / Flexibility Options in the Business Process
-NA-
Outputs The patient takes appointment if he is interested to re-visit the hospital.
Following reports are generated for a post-visit follow-up of patients
o The patients who have taken the appointment on the doctor have advised date.
o The patients who have taken the appointment, but not on doctors advised date.
o The patient who rejected to take appointment.
o Not contacted patients (Not able to contact the patient)
Messages An auto generated SMS is sent to the patient after fixing the appointmentException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In Everyday an auto-generated report is received to the PRM about the Post visit follow-up.Trigger Out Appointment may be fixed.Assumptions Report is received to the PRM and Appointments scheduler is accessible to the PRM users
3.1.8.2 Input Attributes
Atribute Name Attribute Description
Nature of Data
Element
(MOC)
Data Type
Length
/ Size
List Of Values/Co
de Set
Conditions
LogicDefault Value
Capture Method (T/TA/C/R/D/L/L
BL)
Operations (I/D/U/
Q)
Originating
Service/Device
Remarks
UHID Patient UHID M Varchar 10 T Q Registra
tion
For Internal Use Page 23 of 232
MedMantra Software Requirements Specifications ver.0.1
Title Title M Varchar 30 Title 07 Mr. D Q Registra
tion
First Name Patients First Name O Varch
ar 50 T Q Registration
Middle Name Patients Middle Name O Varch
ar 50 T Q Registration
Last Name Patients Last Name O Varch
ar 50 T Q Registration
Doctors advised Date
Doctors advised date to re-visit M
Date Time
T Q Appointment Date & Time Appointment
Date & Time M Date Time T U/Q Appoint
ments
Preferred Mode of Contact
Mode of Contact preferred by the patient
M Varchar 50 Mode of
contact 08 Telephone D Q Registra
tion
Contact Number
Contact Number of the patient
C Number 15
If preferr
ed mode
of contact
is telepho
ne
T Q
Address Patients Address C Varch
ar 100
If preferr
ed mode
of contact is snail
T Q
Department name
Department name to which Patient needs to contact
M Varchar 50 T Q
Department Location Address
Address of Department to which patient needs to contact
M Varchar 100 T Q
Contact person to meet
Contact person name to which Patient needs to contact
M Varchar 50 T Q
Ref. Dr. Name Referral Doctor Name O Varch
ar 50 T Q
Ref. Dr. Mode of Contact
Referral Doctor communication channel preferred C
Varchar
50 Mode of contact 08
If Referral Dr. is selected
Telephone
D Q
Ref. Dr. Address
Referral Doctor Address C Varch
ar 100
If preferr
ed mode
of contact is snail
T Q
Ref. Dr. Contact
Referral Doctor contact number C Numb
er 50 If preferr T Q
For Internal Use Page 24 of 232
MedMantra Software Requirements Specifications ver.0.1
Number
ed mode
of contact
is telepho
nePre-requisite details Pre-requisite
details M Varchar 50 T Q
Call Status Status of the Call M Varch
ar 50 Call Status 13 Open D U/Q
Next Date Time to call
Future date to call the patient, when the patient asks PRM to call after sometime
C Date Time
If Call status is call later
T I/D/U/Q
Did they take the medicine prescribed by the doctor
Yes or No C Yes No
If yes- medicin
e efficacy askedIf NO- reason capture
d
Is the patient willing to come to the hospital
Next appointment is scheduled based on this
Yes or no
Appointment
scheduled/
caller not
interseted
Remarks Remarks if any C Varchar 200
If Call status is not
interested,
then Remar
ks should
be capture
d
TA I/D/U/Q
3.1.8.3 Prescrption Follow upPRM informs the patient about Doctor prescribed medicine.
For Internal Use Page 25 of 232
MedMantra Software Requirements Specifications ver.0.1
Figure 2 : Prescription Follow-up
3.1.8.4 Business Process
Business Process DetailsDescription The follow-up of patients who has to take prescription medicine Users with access control
PRM Users
For Internal Use Page 26 of 232
MedMantra Software Requirements Specifications ver.0.1
Pre – requisites
The doctor should prescribe the medicine.The patient did not collect medicine from the Pharmacy or Patient needs to collect medicine after a few days under treatment process.
Business Process Details
Process Description
PRM gets a report for every 5 hours on the patients who are not taken Doctor prescribed medicine from Apollo Pharmacy.
PRM gets another report of all the patients on long term who have to take the medicine from pharmacy prior to 1 week.
The report contains the details of the patient from the Registration module, Patient record module, Billing & Pharmacy like
o Patient name
o Contact number
o E-mail ID
o Prescription
o Cost of the medicine
o Nearest Pharmacy – (searchable when address of patient is changed)
o Date of medicine
The patient is informed about the doctors prescription
If medicine cost is greater than X amount then, the PRM asks the patient ‘Does he needs Home delivery facility’.
If patient wants home delivery then, an alert is sent to nearest located Pharmacy for Home delivery of drug.
If medicine cost is less than X amount or patient is not interested in Home delivery facility then, the patient is informed about potential interactions with the prescribed drug (food, alcohol, other medicines, pregnancy, etc.) and patient is asked to collect medicines from the nearest Pharmacy.
PRM updates the status of the call (closed/pending)
Business Rules PRM gets a report for every 5 hours on the patients who are not taken Doctor
prescribed medicine from Apollo Pharmacy.
PRM gets another report of all the patients on long term who have to take the medicine from pharmacy prior to 1 week.
When drug is prescribed by doctor, the potential drug interactions must be shown automatically triggering from the Patient Record/Doctors/wards module
For Internal Use Page 27 of 232
MedMantra Software Requirements Specifications ver.0.1
Email is sent automatically from the Pharmacy to the patients who have to take prescribed medicine. The mail/E-mail contains the prescription details, anti drugs, list of food items that are anti to drug, nearest pharmacy details…
X amount should be defined for home delivery
Alternate / Flexibility Options in the Business Process
NA
Outputs Patient is informed about the medicine; he/she needs to purchase.
Reports are generated on
o List of patients accepted for home delivery
o List of patients rejected for home delivery
o List of patients who collected prescribed medicine from the pharmacy.
o List of patients rejected to purchase medicine.
Messages An alert is sent to the pharmacy about the home delivery of medicine to the patients.Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In Worklist is created by pulling information from Pharmacy which contains the list
of patients who has to take medicine.Trigger Out When patient asks for home delivery of medicines, then the home delivery process of
Pharmacy receives an alert from the PRM and the process is initiated.Assumptions -NA-
3.1.8.5 Input/Attributes
Attribute Name
Attribute Description
Nature of Data Element (MOC)
Data Type
Length / Size
List Of Values/Code Set
Conditions Logic
Default Value
Capture Method
(T/TA/C/R/D/L/LBL)
Operations (I/D/U/Q)
Originating
Service/Devi
ce
Remarks
UHID Patient UHID M Varchar 10 T Q Registr
ation
Title Title M Varchar 30 Title 07 Mr. D Q Registr
ation
First Name Patients First Name O Varch
ar 50 T Q Registration
Middle Name Patients Middle
Name O Varchar 50 T Q Registr
ation
Last Name Patients Last Name O Varch
ar 50 T Q Registration
Appointment Date & Time
Appointment Date & Time
M DateTime
T U/Q Appointments
For Internal Use Page 28 of 232
MedMantra Software Requirements Specifications ver.0.1
Preferred Mode of Contact
Mode of Contact preferred by the patient
M Varchar 50
Mode of contact 08 Telephone D Q Registr
ation
Contact Number
Contact Number of the patient
C
Number 15
If preferred mode of
contact is telephone
T Q
Address Patients Address C Varch
ar 100
If preferred mode of
contact is snail mail
T Q
Cost of medicine
Doctor prescribed medicine cost M
Number 15 T Q
Medicine date
Date on which the patient should take medicine
M DateTime T Q
LocationPresent location of the patient
O Varchar 50
Location of the patient, the nearest pharmacy address should be populated. A search is also provided by giving a search option
T I/D/U/Q
The nearest pharmacy address should be auto populated, when the text is entered in the textbox
Nearest Pharmacy
Nearest Pharmacy address
M Varchar 150 TA Q
This will be populated based on the location
Call Status Status of the Call
M Varchar
50 Call Status 13
Open D U/Q
Next Date to call
Future date to call the patient, when the patient asks PRM to call after sometime
C DateTime
If Call status is call later
T I/D/U/Q
Remarks Remarks if any C Varchar 200
If Call status is
not interested,
TA I/D/U/Q
For Internal Use Page 29 of 232
MedMantra Software Requirements Specifications ver.0.1
then Remarks should be captured
Process Checklists
S. No
Check list
Code
Check list
Name
Description
Triggering Event
Check Items
Business Rules for Generation
-NA-
Alerts / Reminders / Notifications
Sr. NoRequest Code Request Name Time Limit Action Required
Alert MessageNotify UserNotify mechanism
Remarks
1 PRM1 Home delivery of medicine
After medicine is delivered, it should be updated
Home delivery details to the pharmacy
Pharmacy Alert
2 PRM2 Email to patient about medicine
After 3 hours of doctor prescription of medicine
Email should be sent to the patient
Medicine details & nearest pharmacy details
Patient Email
For Internal Use Page 30 of 232
MedMantra Software Requirements Specifications ver.0.1
3.1.9 Enquiry Dashboard
Description The patient enquiry list is designed to manage the various enquiries comes to the hospital through various sources call/E-mail/Walk in or through website. Though most of the enquiries come through call centre certain enquiries also come to the front office/any patient care areas. Based on the enquiry detailed information on the specific details which are requested by the patient are provided. In some cases the information required to answer the query might not be available at the Front Desk in that case they should be able to divert the call to the respective / concerned department.
PROCESS COMMENCE- Once the patient/guest/Attender asks for information.PROCESS END- Query is responded & closed with information received by the desired person.
While Answering Enquiry Information provison to access the Various Information To be available( refer to information Dashboard)
The enquiry comes in from different quarters of the hospitals & mainly through the call center or front office. Benefits would be
a. The real time tracking OF ENQUIRY
b. Also information can get lost in shifting of duties of the staff
c. Centralized Query Management System which facilitates Quick & Customized Responses
d. Assessing the work load & Efficiency of staff is only possible only if centralized query management is in place.
e. Multiple channels of getting queries are not integrated hence results cannot be delivered in a single report. Using HIS No matter which Enquiry channels you use
For Internal Use Page 31 of 232
MedMantra Software Requirements Specifications ver.0.1
—Web, telephone, or email—all the results can be delivered in a single report so you don’t lose valuable insight in silos
f. Retrieval /search an earlier query for follow up would be easy. Also assigning to concerned department will be easy as it can be immediately addressed by the assigned staff.
g. Tracking each enquiry till closure becomes difficult also can lose track which huge volume of enquiries.
h. Most of the time is spent wading through data at the expense of taking action.
i. Complete history of the enquiry
Process Specification:
1. System should be able to manage Enquiry Registration – Records all the enquiries that can come from various sources like email, website, and telephone.
2. PRN generation link required in enquiry form
3. System should be able to link the details of the customer and details should auto populate if the customer has an existing UHID.
4. The system should have configurability to create Enquiry type, Source and Priority depending upon the requirements of location.
5. System should be able to save, close, assign or Follow Up status depending upon the enquiry received.
6. System should be capable to capture the information given to customer and should also be capable to send the same via web, fax or sms (sms depending upon the character length) with the login id users name so that the same can be validated in future visits or episodes as applicable.
7. Follow-Up – The most important step of any enquiry management system is to follow-up, which avoids the enquiry going unattended and that saves from losing a business prospect. This includes recording the follow-up; attach documents and finally recording the status of that enquiry.
8. System should have configurability option so that after certain TAT depending upon the enquiry type it should automatically distributed among PRM staff under the category of Follow Up.
9. System should be capable to Assign query to other department- In case of special queries which needs to be answered by specific department/person .The initial query recorded & assigned to respective department/person.
10. System should be able to re assign till the status is closed.
11. System should be capable enough to track the changes made in remark done by each logger associated with the closing of activity and should be able to depict in Audit Trail.
For Internal Use Page 32 of 232
MedMantra Software Requirements Specifications ver.0.1
12. System should also be able to assign multiple specialties depending upon the nature of the call.
13. System should be capable enough to configure no of days that has crossed without the call being closed based upon that there should be provision to map level 1 and level 2 escalation against type of Enquiry.
14. Further the login id of level 1 and level 2 should be attached so that the escalation hits their official mail id as priority and severity as defined in the Masters.
15. System should be able to provide TAT reports on each type of query when escalation happens depending upon any time search criteria.
16. Receive timely Reminders for important follow-ups
17. History of follow-up done and document shared with customer
Users with access control
1.Call center staff2. Front line staff3. All concerned departments 4. Service Excellence Managers.
Pre – requisites
1. Enquiry form has to be filled.2. Query has to be received from the customer can be from multiple sources.3. Other than manual source all other sources needs to be integrated i.e. Email ID on
the website etc.
Business Process Details
The patient enquiry screen provides different aspects of information for the patient to help them in their treatment process. The patient enquiry screen includes options for entering various patient details which includes name, address, telephone number, IP number and various other information which is required to be entered into the specific fields of the patient enquiry screen. If the query can be answered completely then the it is closed. If query details are not currently available then
Query will saved & followed up after Information gathered from other departments/source of information
If the query is special category such as medical query /International customer query which has to be answered by qualified person then these queries will be assigned to particular person/department ( set up required to define which type of queries can be assigned & to whom)
Work list for appointment follow up will be shown two grids All queries which have been Assigned All other queries which have to followed up from different source
Should have separate link of day end closure call/follow-up list – All pending calls/follow up for that day have to displayed. This list can be populated based on business rule which will define the cut off time which would be taken as basis for generating the pending list for that day.
Provision to differentiate high priority items through some mechanism (sort/ color code etc ) Such as call u back status calls/ follow ups which have nearing/crossed
For Internal Use Page 33 of 232
MedMantra Software Requirements Specifications ver.0.1
the SLA defined times to close the query. During the call user should be able to send the details of the appointment /query
through SMS, email, mail etc.
Business Rules for Work list creation(refer to common business rules for reminder/follow up activities – Call centre creation)
System should allow the user to set the time for the follow up call say on next day / after x hour of the query made by the customer each customer will get the follow up call to close the query
The system should able to manage the rule for non working days of the call center. Say all appointments (/follow up to be closed) of Monday will be reminded on Saturday.
Hence system is able to find the total number of calls to be made on a particular day and time.
The system should have the capability to assign the reminder call list as per the following logic to manage the call loads among the call center executive deployed to manage the reminder calls.(refer to call load management businness rule from common business rules for reminder/follow up activities
Note: system only sends the items only to the members eligible for that center not to other executives.
The usage of the functionality shall be to follow up & close the enquiries patients scheduled for various services before a predefined period of time.
Objectives would be to Manage and track calls, emails and book & follow up enquiries(through
other modes of communication also) Maintain patient details Provide pre-visit information to the patient if required
Business Rule:
A unique Enquiry id will be created with enquiry details. There can be multiple enquiry ids against unique customer / UHID.
In case of Assignment and re assignment the enquiry id will be same. System to allow updating against the enquiry id till status is closed. Whenever Remark column is updated it has to go through Audit Trail. When the enquiry id is clicked then that cant be accessed by any other user. If specified SLA is crossed then escalation to be raised to concerned login id as per
set up.
The work list dashboard will have following attributes
Enquiry NO.- Generated once an enquiry is logged in
Caller Name – At tender/patient who has given the call to the call centre department
Customer/patient name- actual person for whom the enquiry has been made by the attender
For Internal Use Page 34 of 232
MedMantra Software Requirements Specifications ver.0.1
UHID- UHID of the hospital if available.
Contact details – mobile number & E-mail ID
Location – city & area from where they are calling
Source of enquiry- Call /E-mail/website etc
Enquiry type – Appointment/medical opinion/information query etc
Agent- The name of the person who has taken the call/attended the query
Secretary name- In case of OP related queries who has given the information regarding the doctor availability/fixing the appointment etc
Department – against which the query is directed to all specialty
Doctor Name- If any query is directed to the availability of certain doctor
Remarks- Multiline text box ( Alpha numerical with special characters)
Option to Assign the query to relevant department if required( as per managements decision)
Provision to view call history will be available- caller details, date& time & remarks if any
PRM users gather the patient pre-requisites information from the help desk. The mode of follow up can be various media including, SMS, Telephone calls and
emails.
PRM users call the Patient/Attendant and inform about the appointment, find out the patient’s existing UHID or help the patient generate a PRN. If an email reminder is sent a link to a pre-registration form should be included. This pre-registration form should generate a PRN for the patient.
If patient is willing to come to the hospital at the fixed appointment time, then the following information is passed on to the patient
o Pre-requisites before visiting the hospital
o Appointment Date & time
o Location
o Contact person to meet
If patient wants to remind after some period, then the Next Date Time to call is fixed and automatic alert is received to the PRM for reminding the patient.
Email: Similar process as SMS.
Business Rules for Reminders
Reminder required
For Internal Use Page 35 of 232
MedMantra Software Requirements Specifications ver.0.1
Follow up Yes After x days /y hours of scheduled appointment
HIPAA: A covered entity also may leave a message with a family member or other person who answers the phone when the patient is not home. The Privacy Rule permits covered entities to disclose limited information to family members, friends, or other persons regarding an individual’s care, even when the individual is not present. However, covered entities should use professional judgment to assure that such disclosures are in the best interest of the individual and limit the information disclosed. See 45 CFR 164.510(b)(3).
Alternate / Flexibility Options in the Business Process
-NA-
OutputsMessagesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-
Trigger In -NA-
Trigger Out -NA-
Assumptions -NA-
For Internal Use Page 36 of 232
MedMantra Software Requirements Specifications ver.0.1
3.1.9.1 Enquiry Form
Proposed UI for Enquiry Form
3.1.9.1.1 Input/Attributes
Attribute Name
Attribute Description
Nature of Data Element (MOC)
Data Type Length / Size
List Of Values/Co
de SetConditions Logic Remark
s
UHID Patient UHID O Varchar 10 Title Title M Varchar 30 Title 07 First Name Patients First Name O Varchar 50
Middle Name Patients Middle Name O Varchar 50
Last Name Patients Last Name O Varchar 50 Title Title M Varchar 30 Title 07 First Name Caller First Name O Varchar 50 Middle Name Caller Middle Name O Varchar 50 Last Name Caller Last Name O Varchar 50 Query Date & Time
Appointment Date & Time M Date Time
Date Of Birth Date of Birth M Age/DOB 8Preferred Mode of Contact
Mode of Contact preferred by the patient
M Varchar 50 Mode of contact 08
Contact Number
Contact Number of the patient C Number 15 If preferred mode of
contact is telephone
For Internal Use Page 37 of 232
MedMantra Software Requirements Specifications ver.0.1
Address Patients Address C Varchar 100 If preferred mode of contact is snail mail
Enquiry status Status of the Enquiry M Varchar 50 Enquiry Status
Enquiry TypeTypeof Enquiry
M Varchar 50 Enquiry TYpe
Ref. Dr. Name Referral Doctor Name O Varchar 50
Source Source from which enquiry is received Varchar Source of
enquuiry
Prority Proprity of the enquiry Varchar Proirity of
enquiryEnquiry description Varchar 200
Corporate Name
Working Organization name O Varchar 50
Remarks Remarks if any C Varchar 200 If Call status is not
interested, then Remarks should be captured
Follow up Activity
For assigned person /Pending query the follow through various channels are conducted
O Through Fax/E-mail/Call etc
3.1.9.1.2 Business Process
Description Once an enquiry received through any source , Enquiry form is filled & Enquiry ID is generated. This becomes an worklist item in the dashboard.
Process Specification:
1. System should be able to manage Enquiry Registration – Records all the enquiries that can come from various sources like email, website, and telephone.
2. System should be able to link the details of the customer and details should auto populate if the customer has an existing UHID.
3. The system should have configurability to create Enquiry type, Source and Priority depending upon the requirements of location.
4. System should be able to save, close, assign or Follow Up status depending
For Internal Use Page 38 of 232
MedMantra Software Requirements Specifications ver.0.1
upon the enquiry received.
5. System should be capable to capture the information given to customer and should also be capable to send the same via web, fax or sms (sms depending upon the character length) with the login id users name so that the same can be validated in future visits or episodes as applicable.
6. Follow-Up – The most important step of any enquiry management system is to follow-up, which avoids the enquiry going unattended and that saves from losing a business prospect. This includes recording the follow-up; attach documents and finally recording the status of that enquiry.
7. System should have configurability option so that after certain TAT depending upon the enquiry type it should automatically distributed among PRM staff under the category of Follow Up.
8. System should be capable to Assign query to other department- In case of special queries which needs to be answered by specific department/person .The initial query recorded & assigned to respective department/person.
9. System should be able to re assign till the status is closed.
10. System should be capable enough to track the changes made in remark done by each logger associated with the closing of activity and should be able to depict in Audit Trail.
11. System should also be able to assign multiple specialties depending upon the nature of the call.
Users with access control
1.Call center staff2. Front line staff3. All concerned departments 4. Service Excellence Managers.
Pre – requisites
1. Query has to be received from the customer can be from multiple sources.2. Other than manual source all other sources needs to be integrated i.e. Email ID on
the website etc.
Business Process Details
The patient enquiry screen includes options for entering various patient details which includes
Name- Both Caller Name & patient Name for whom the enquiry is been asked for
Address/Location – As per registration LOV
,Telephone number-E-mail ID -As per standard Format to capture these details
UHID/ Patient Identifier – If the patient is an existing customer
Customer type- Whether domestic or international etc
Age/DOB – whichever is available
For Internal Use Page 39 of 232
MedMantra Software Requirements Specifications ver.0.1
Enquiry Type – List of values of dropdown to be maintained
For e.g.- appointment/ Information query/Medical query etc
If the enquiry type is Enquiry type then Secretary name who has co- ordinate in booking an appointment is also captured.(through Appointment booking link)
Source of enquiry – E-mail/Call/SMS etc
Priority- LOV to be maintained , could be numerical/Alphabetical (high/mediumetc)
Enquiry details – Brief description of enquiry is captured along with
Remarks if any
If the query can be answered completely then the it is closed. If query details are not currently available then
Query will saved & followed up after Information gathered from other departments/source of information
If the query is special category such as medical query /International customer query which has to be answered by qualified person then these queries will be assigned to particular person/department ( Configuration required to define which type of queries can be assigned & to whom)
Business Rule:
A unique Enquiry id will be created with enquiry details. There can be multiple enquiry ids against unique customer / UHID.
In case of Assignment and re assignment the enquiry id will be same. System to allow updating against the enquiry id till status is closed. Whenever Remark column is updated it has to go through Audit Trail. When the enquiry id is clicked then that cant be accessed by any other user.
Alternate / Flexibility Options in the Business Process
-NA-
OutputsMessagesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-
Trigger In -NA-
Trigger Out -NA-
Assumptions -NA-
For Internal Use Page 40 of 232
MedMantra Software Requirements Specifications ver.0.1
3.1.9.2 Work List
Work List – Draft UI
3.1.9.2.1 Business ProcessDescription Work list for Enquiry follow up will be shown two grids
All queries which have been Assigned All other queries which have to followed up from different source
Should have separate link of day end closure call/follow-up list – All pending calls/follow up for that day have to displayed. This list can be populated based on business rule which will define the cut off time which would be taken as basis for generating the pending list for that day.
Provision to differentiate high priority items through some mechanism (sort/ color code etc ) Such as call u back status calls/ follow ups which have nearing/crossed the SLA defined times to close the query.
During the call user should be able to send the details of the appointment /query through SMS, email, mail etc.
While Answering Enquiry Information provison to access the Various Information To be available( refer to information Dashboard)
For Internal Use Page 41 of 232
MedMantra Software Requirements Specifications ver.0.1
System should manage:
1. Follow-Up – The most important step of any enquiry management system is to follow-up, which avoids the enquiry going unattended and that saves from losing a business prospect. This includes recording the follow-up; attach documents and finally recording the status of that enquiry.
2. System should have configurability option so that after certain TAT depending upon the enquiry type it should automatically distributed among PRM staff under the category of Follow Up.
3. View enquiry option to be provided for both assigned & follow up enquiries
4. System should be capable to Assign query to other department- In case of special queries which needs to be answered by specific department/person .The initial query recorded & assigned to respective department/person.
5. System should be able to re assign till the status is closed.
6. System should be capable enough to track the changes made in remark done by each logger associated with the closing of activity and should be able to depict in Audit Trail.
7. System should also be able to assign multiple specialties depending upon the nature of the call.
8. System should be capable enough to configure no of days that has crossed without the call being closed based upon that there should be provision to map level 1 and level 2 escalation against type of Enquiry.
9. Further the login id of level 1 and level 2 should be attached so that the escalation hits their official mail id as priority and severity as defined in the Masters.
10. System should be able to provide TAT reports on each type of query when escalation happens depending upon any time search criteria.
11. Receive timely Reminders for important follow-ups
12. History of follow-up done and document shared with customer
Users with access control
1.Call center staff2. Front line staff
Pre – requisites
1. Enquiry form has to be filled.2. Query has to be received from the customer can be from multiple sources.3. Other than manual source all other sources needs to be integrated i.e. Email ID on
the website etc.
Business Process Details
Business Rules for Work list creation(refer to common business rules for reminder/follow up activities – Call centre creation)
System should allow the user to set the time for the follow up call say on next day /
For Internal Use Page 42 of 232
MedMantra Software Requirements Specifications ver.0.1
after x hour of the query made by the customer each customer will get the follow up call to close the query
The system should able to manage the rule for non working days of the call center. Say all appointments (/follow up to be closed) of Monday will be reminded on Saturday.
Hence system is able to find the total number of calls to be made on a particular day and time.
The system should have the capability to assign the reminder call list as per the following logic to manage the call loads among the call center executive deployed to manage the reminder calls.(refer to call load management businness rule from common business rules for reminder/follow up activities
Note: system only sends the items only to the members eligible for that center not to other executives.
The usage of the functionality shall be to follow up & close the enquiries patients scheduled for various services before a predefined period of time.
Objectives would be to Manage and track calls, emails and book & follow up enquiries(through
other modes of communication also) Maintain patient details Provide pre-visit information to the patient if required
Business Rule:
In case of Assignment and re assignment the enquiry id will be same. System to allow updating against the enquiry id till status is closed. Whenever Remark column is updated it has to go through Audit Trail. When the enquiry id is clicked then that cant be accessed by any other user. If specified SLA is crossed then escalation to be raised to concerned login id as per
set up.
The work list dashboard will have following attributes
Enquiry NO.- Generated once an enquiry is logged in
Caller Name – At tender/patient who has given the call to the call centre department
Patient Name- for whom the query has been asked for.
UHID- UHID of the hospital if available.
Contact details – mobile number & E-mail ID
Location – city & area from where they are calling
Source of enquiry- Call /E-mail/website etc
Enquiry type – Appointment/medical opinion/information query etc
Agent- The name of the person who has taken the call/attended the query
Secretary name- In case of OP related queries who has given the
For Internal Use Page 43 of 232
MedMantra Software Requirements Specifications ver.0.1
information regarding the doctor availability/fixing the appointment etc
Department – against which the query is directed to all specialty
Doctor Name- If any query is directed to the availability of certain doctor
Remarks- Multiline text box ( Alpha numerical with special characters)
Option to Assign the query to relevant department if required( as per managements decision)
Provision to view call history will be available- caller details, date& time & remarks if any
PRM users gather the patient pre-requisites information from the help desk. The mode of follow up can be various media including, SMS, Telephone calls and
emails.
PRM users call the Patient/Attendant and inform about the appointment, find out the patient’s existing UHID or help the patient generate a PRN. If an email reminder is sent a link to a pre-registration form should be included. This pre-registration form should generate a PRN for the patient.
If patient is willing to come to the hospital at the fixed appointment time, then the following information is passed on to the patient
o Pre-requisites before visiting the hospital
o Appointment Date & time
o Location
o Contact person to meet
If patient wants to remind after some period, then the Next Date Time to call is fixed and automatic alert is received to the PRM for reminding the patient.
Email: Similar process as SMS.
Business Rules Assigned Query should have Reassign option. In case of Assignment and re assignment the enquiry id will be same. System to allow updating against the enquiry id till status is closed. Whenever Remark column is updated it has to go through Audit Trail. When the enquiry id is clicked then that cant be accessed by any other user.
Business Rules for Reminders
Reminder required
Follow up Yes After x days /y hours of date& time of enquiry Email: Similar process as SMS.
HIPAA: A covered entity also may leave a message with a family member or other
For Internal Use Page 44 of 232
MedMantra Software Requirements Specifications ver.0.1
person who answers the phone when the patient is not home. The Privacy Rule permits covered entities to disclose limited information to family members, friends, or other persons regarding an individual’s care, even when the individual is not present. However, covered entities should use professional judgment to assure that such disclosures are in the best interest of the individual and limit the information disclosed. See 45 CFR 164.510(b)(3).
Alternate / Flexibility Options in the Business Process
-NA-
OutputsMessagesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-
Trigger In -NA-
Trigger Out -NA-
Assumptions -NA-
3.1.9.3 Assigned Queries Work List3.1.9.3.1 Business Process
Description Work list for Assigned Enquiry All queries which have been Assigned wil appear in assigned person Login As per the SLA defined for that particular type of enquiry – Pending Enquiries are
escalated.. Provision to differentiate high priority items through some mechanism (sort/ color
code etc ) Such as call u back status calls/ follow ups which have nearing/crossed the SLA defined times to close the query.
Follow up activity through various Channels to be captured & history of follow up to be maintained
Reports if any are sent by the Patien provsion to upload – The same to appended as out side reports section to patient record if the UHID is created & patient has visited the hospital as an OP/IP .
Query resolution date & time are captured Also the Resolution remarks. While Answering Enquiry Information provison to access the Various Information
To be available( refer to information Dashboard)
System should manage:
1. Follow-Up – The most important step of any enquiry management system is to follow-up, which avoids the enquiry going unattended and that saves from losing a business prospect. This includes recording the follow-up; attach documents and finally recording the status of that enquiry.
For Internal Use Page 45 of 232
MedMantra Software Requirements Specifications ver.0.1
2. System should have configurability option so that after certain TAT depending upon the enquiry type it should automatically distributed among PRM staff under the category of Follow Up.
3. View enquiry option to be provided for both assigned & follow up enquiries.
4. System should be capable to Assign query to other department- In case of special queries which needs to be answered by specific department/person .The initial query recorded & assigned to respective department/person.
5. System should be able to re assign till the status is closed.
6. System should be capable enough to track the changes made in remark done by each logger associated with the closing of activity and should be able to depict in Audit Trail.
7. System should be capable enough to configure no of days that has crossed without the call being closed based upon that there should be provision to map level 1 and level 2 escalation against type of Enquiry.
8. Further the login id of level 1 and level 2 should be attached so that the escalation hits their official mail id as priority and severity as defined in the Masters.
9. System should be able to provide TAT reports on each type of query when escalation happens depending upon any time search criteria.
10. Receive timely Reminders for important follow-ups
11. History of follow-up done and document shared with customer
Users with access controlPre – requisites Business Process Details
The work list dashboard will have following attributes
Enquiry NO.- Generated once an enquiry is logged in
Caller Name – At tender/patient who has given the call to the call centre department
Patient Name- for whom the query has been asked for.
UHID- UHID of the hospital if available.
Contact details – mobile number & E-mail ID
Location – city & area from where they are calling
Source of enquiry- Call /E-mail/website etc
For Internal Use Page 46 of 232
MedMantra Software Requirements Specifications ver.0.1
Enquiry type – Appointment/medical opinion/information query etc
Agent- The name of the person who has taken the call/attended the query
Secretary name- In case of OP related queries who has given the information regarding the doctor availability/fixing the appointment etc
Department – against which the query is directed to all specialty
Doctor Name- If any query is directed to the availability of certain doctor
Remarks- Multiline text box ( Alpha numerical with special characters)
Option to Reassign the query to relevant department if required( as per managements decision)
Provision to view call history will be available- caller details, date& time & remarks if any
PRM users gather the patient pre-requisites information from the help desk. The mode of follow up can be various media including, SMS, Telephone calls and
emails.
PRM users call the Patient/Attendant and inform about the appointment, find out the patient’s existing UHID or help the patient generate a PRN. If an email reminder is sent a link to a pre-registration form should be included. This pre-registration form should generate a PRN for the patient.
If patient is willing to come to the hospital at the fixed appointment time, then the following information is passed on to the patient
o Pre-requisites before visiting the hospital
o Appointment Date & time
o Location
o Contact person to meet
If patient wants to remind after some period, then the Next Date Time to call is fixed and automatic alert is received to the PRM for reminding the patient.
Email: Similar process as SMS.
Business Rules for Reminders
Reminder required
Follow up Yes After x days /y hours of date& time of enquiry
HIPAA: A covered entity also may leave a message with a family member or other person who answers the phone when the patient is not home. The Privacy Rule permits covered entities to disclose limited information to family members, friends,
For Internal Use Page 47 of 232
MedMantra Software Requirements Specifications ver.0.1
or other persons regarding an individual’s care, even when the individual is not present. However, covered entities should use professional judgment to assure that such disclosures are in the best interest of the individual and limit the information disclosed. See 45 CFR 164.510(b)(3).
Alternate / Flexibility Options in the Business Process
-NA-
OutputsMessagesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-
Trigger In -NA-
Trigger Out -NA-
Assumptions -NA-
3.1.9.3.2 Input/Attributes
Attribute Name
Attribute Description
Nature of Data
Element (MOC)
Data Type Length / Size
List Of Values/Code
SetCondition
s LogicOriginating
Service/DeviceRemar
ks
UHID Patient UHID O Varchar 10 RegistrationTitle Title M Varchar 30 Title 07 Registration
First Name Patients First Name O Varchar 50 Registration
Middle Name Patients Middle Name O Varchar 50 Registration
Last Name Patients Last Name O Varchar 50 Registration
Title Title M Varchar 30 Title 07 RegistrationFirst Name Caller First Name O Varchar 50 Registration
Middle Name Caller Middle Name O Varchar 50 Registration
Last Name Caller Last Name O Varchar 50 RegistrationQuery Date & Time
Appointment Date & Time M Date Time Appointments
Date Of Birth Date of Birth M Age/DOB 8Preferred Mode of Contact
Mode of Contact preferred by the patient
M Varchar 50 Mode of contact 08 Registration
For Internal Use Page 48 of 232
MedMantra Software Requirements Specifications ver.0.1
Contact Number
Contact Number of the patient C Number 15
If preferred mode of
contact is telephone
Address Patients Address C Varchar 100
If preferred mode of
contact is snail mail
Enquiry status
Status of the Enquiry M Varchar 50 Enquiry Status
Enquiry TypeTypeof Enquiry
M Varchar 50 Enquiry TYpe
Ref. Dr. Name Referral Doctor Name O Varchar 50
SourceSource from which enquiry is received
Varchar Source of enquuiry
Prority Proprity of the enquiry Varchar Proirity of
enquiry
Next Date Time to call
Future date to call the patient, when the patient asks PRM to call after sometime
C Date Time If Call
status is call later
Follow up of pending enquiry
Follow up to be made of intial enquiry
O
Will hit the worklist of pending enquiries
Remarks Remarks if any C
Varchar
200
If Call status is
not interested
, then Remarks should be captured
Follow up Activity
For assigned person /Pending query the follow through various channels are conducted
O
Through Fax/E-
mail/Call etc
For Internal Use Page 49 of 232
MedMantra Software Requirements Specifications ver.0.1
3.1.10 Information Dashborad
Draft UI for Information dashboard
3.1.10.1 Business Process
Description Information dashboard organizes and presents the important information from large amounts of data in a way that it is easy to understand for the user. It combines data from different sources and directs user’s attention to the most relevant information so that they can quickly identify the information they are looking for. The dashboard will contain all the information to answer the frequently asked questions/queries by the caller.
Sysytem should be capable in integrating all sources of Information requets (Request for information to reach the PRM user who answers the Enquiries)
Users with access control
PRM Users – read/write access
Pre – requisites
PRM requires the query from the patients who want to use /have used the hospital services.
Business Process Details Information Dash Board will have basic information on
For Internal Use Page 50 of 232
MedMantra Software Requirements Specifications ver.0.1
Apollo sites- Hospital location/ Pharmacy Locations/Apollo Life Information retrieved & other tied –up hospitals from Apollo website
Consultation – Doctors available /specialty/location etc. Facilities /services - availability in a particular location along with hospital cash
tariff .location map with in the hospital.(mapped against the service ID/name in service master along with patient education material)
Patient status- Both OP/IP patient status updated from respective modules Tariff- service name & tariff will be displayed –only for specific users Estimation- Estimates as in billing for privileged users Logistics- Ambulance availability information & courier tracking in & out of the hospital Report status- Lab & Radiology test report status updated from respective modules
Process Description:
Customer wants some information about the hospital/ Doctor consultation/ other hospital services (Human/Equipment).
The source of asking the information can be from various media including, SMS, Telephone calls, websites and emails.
PRM users get the daily/monthly report of all patients whose mode of communication is Telephone/Mail etc.
PRM users should be able to give the patient pre-requisites information about the service (if any).
PRM users should be able to give the patient/service location map information(through print) related the query.
a. Facility/services in service master to be mapped with the location map , Pre-requisites & service availability at the particular location
PRM users call the Patient/Attendant and inform about the appointment/service, find out the patient’s existing UHID or help the patient generate a PRN.
If patient is willing to come to the hospital at the fixed appointment time, then the following information is passed on to the patient
a. Pre-requisites before visiting the hospitalb. Appointment Date & timec. Location d. Contact person to meet
System should be able to provide information on the sub category & search by location should give you complete hospital details such as postal address ,telephone numbers , e-mail ID’s, Fax no.etc along with location map .(Google location map). Also Useful numbers such as Emergency, Helpdesk, Blood Bank, Preventive Health Checkup, Director of Medical Services, PRO, International Patients extension numbers.
It should have the flexibility to search location within a city similar to the data of Registration Module.
If patient requests to send it through E-mail then email address of the patient to be taken & reports to be sent to the email ID.
Updated e-mail ID to reflect in registration details
System should be capable to display Search options by Location (with in city) & city, service name/facility name/tariff/ Booking slots/Blocked Slots of all kind of Resources.
System should be able to show whether the service/ facility is available at that particular location & available days & timings service and facility wise.
The system should have flexibility to define tariff accessibility according to location needs.
For Internal Use Page 51 of 232
MedMantra Software Requirements Specifications ver.0.1
System should be able to Search by UHID/patient identifier , date of visit, patient name, by consultant name/specialty, by location & city
System should show Results should show the total patient details with contact details, status as updated from respective modules
It should be able to search a service name-Search based on patient type- cash/credit ( if known) & if credit based on company name
Courier /dock number , date sent , courier in the name of patient should be kept in track and the Courier integration to system should be possible so that Docket movement can be tracked to let the patient pass on the information in case of patient request.
System should be able to provide No. of ambulances available at time of enquiry & at what location, nearest ambulance location & contact no. of driver to be displayed.( By Interacting with Ambulance module)
Whenever there is an update option anywhere it should be traceable. If patient requests to send it through E-mail then email address of the patient to be
taken & reports to be sent to the email ID. Updated e-mail ID to reflect in registration details
Alternate / Flexibility Options in the Business Process
-NA-
OutputsMessagesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.1.10.2 Apollo Hopsital Information & Consultant infromation
Description Information on apollo group hospitals , Mamaged hospitals & international hospitals to be avaialble for person who is answering the enquiry.Also Request for information to reach the PRm user who answers the call.
Sysytem should be capable to integrate with website for latest information on apollo sites & consultation
Users with access control
PRM Users – read/write access
Pre – PRM requires the query from the patients who want to use /have used the hospital
For Internal Use Page 52 of 232
MedMantra Software Requirements Specifications ver.0.1
requisites services.
Business Process Details Information Dash Board will have basic information on
Apollo sites- Hospital location/ Pharmacy Locations/Apollo Life Information retrieved & other tied –up hospitals from Apollo website
Consultation – Doctors available /specialty/location etc.
For Apollo Hospital information the following format to be maintained. After searching for relevant location & branch
Business Rule: It should have the flexibility to search location within a city similar to the data of
Registration Module. Alternatevely it can redirect to URL : http://www.apollohospitals.com/hospitals-in-
india.php
Apollo Hospitals Branch Name
Complete Address
Phone Number,
E-mail address information
Fax Information
Useful telephone numbers of that location such as
Emergency
Apollo Health Check
Appointment Desk
International Wing
International Wing (Fax
Apollo Main Pharmacy
Duty Administrator
Corporate / Insurance Desk
Public Relation Officer
And particular Location website. Location Map with directions to reach the hospitals also to be available
Consultants after searching by name/Location Or by specialty
For Internal Use Page 53 of 232
MedMantra Software Requirements Specifications ver.0.1
After searching the details should appear in the following format
Doctor Name link to book appointment to
Specialization be available
Location
Business Rule: It should have the flexibility to search speciality doctor within a city Alternatevely it can redirect to http://www.apollohospitals.com/find_doctor.php?
pag=1
Alternate / Flexibility Options in the Business Process
-NA-
OutputsMessagesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-
For Internal Use Page 54 of 232
MedMantra Software Requirements Specifications ver.0.1
Trigger Out -NA-Assumptions -NA-
3.1.10.3 Facility/Service information
Description Customer wants information on a particular Facilities /services –
The following information needs to be retrieved by the sysytem Availability of service in a particular location along with timigs Location map with in the hospital.(mapped against the service ID/name in
service. Pre- Requisite information of the service Any other related information if business requires in future
Users with access control
PRM Users – read/write access
Pre – requisites
PRM requires the query from the patients who want to use /have used the hospital services.
Business Process Details Information Dash Board will have basic information on
Facilities /services - availability in a particular location along with hospital cash tariff .location map with in the hospital.(mapped against the service ID/name in service.
PRM users should be able to give the patient pre-requisites information about the service (if any).
System should be able to show a. whether the service/ facility is available at that particular location b. Available days & timings service and facility wise.(As define din service
master) PRM users should be able to give the patient/service location map information(through
print) related the query. a. Location Map as defined in service master must be in printable format which
can be given to patient physically , to guide the patient in reaching the particular location in the hospitals
Service map masters need to be updated accordingly. Pre-requiste information before avvailing a particular service needs to be available .(As defined in service master)
Alternate / Flexibility Options in the Business Process
-NA-
Outputs
For Internal Use Page 55 of 232
MedMantra Software Requirements Specifications ver.0.1
MessagesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.1.10.4 Enquiring patient Status
For Internal Use Page 56 of 232
MedMantra Software Requirements Specifications ver.0.1
This diagram describes about the status of the patient.
Figure : Enquiring patient status
For Internal Use Page 57 of 232
MedMantra Software Requirements Specifications ver.0.1
3.1.10.4.1 Business Process
Description The PRM gets a call or when the attendant/relative enquires about the patient location, and then the PRM gets the physical location address at that point of time and provides it to the caller.
The following information needs to be retrieved by the sysytem Availability of service in a particular location along with timigs Location map with in the hospital.(mapped against the service ID/name in
service. Pre- Requisite information of the service Any other related information if business requires in future
Users with access control
PRM Users – read/write access
Pre – requisites
PRM requires the query from the patients who want to use /have used the hospital services.
Business Process Details PRM gets a call, when the patient relative wants to know the status of the patient or
when the attendant/relatives comes to the hospital and enquires about the patient. PRM captures the details of the caller or enquirer.
If privacy field is marked for a patient or for VIP or VVIP patient, then the PRM users reject to give information.
The HIPAA Privacy Rule at 45 CFR 164.510(b) & 45 CFR 164.510(a) permits a health plan (or other covered entity) to disclose to a family member, relative, or close personal friend of the individual, the protected health information (PHI) directly relevant to that person’s involvement with the individual’s care or payment for care.
1. Dates of admission,2. Discharge or other services;3. Dates of birth or death;4. Age of participant (including those over 90 years of age);5. Full six-digit zip code and any other geographic subdivision such as county, city,
precinct, and equivalent geocode (except street address). 6. Health condition in general terms – HIPAA 45 CFR 164.510(a)7. Location in the facility – HIPAA 45 CFR 164.510(a)8. Phone Number of the patients room – HIPAA 45 CFR 164.510(a)
PRM users reject to provide information when they failed to prove their identity.
PRM updates the type of information provided to the enquirer.
Business Rules
For all VIP or VVIP patients the patient status cannot be informed to any one. For all the privacy patients the information is not provided to anyone.
For Internal Use Page 58 of 232
MedMantra Software Requirements Specifications ver.0.1
The Patient is given password at the time of Registration or Admission. So that thePatient/Attendant can get health information of the patient by providing the password.
PRM users reject to provide information when the caller fails to prove his identity. The password validity time period should be customizable. To provide complete patient information, authorization must be needed from the DMS. If a researcher needs county data, the required information is provided – HIPAA 45
CFR 164.514(e)(3)(ii).
Alternate / Flexibility Options in the Business Process
-NA-
OutputsMessagesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 59 of 232
MedMantra Software Requirements Specifications ver.0.1
3.1.10.5 Patient Report Status
Draft UI For Report Status Enquiry Information
3.1.10.5.1 Business Process details
Description Customer wants information on a Report of investigation done in the hospital –
The following information needs to be retrieved by the sysytem Request no. /LRN No/ DRN no. of investigation Patient details such as Name, Gender & age Department – under which the investigation was done Requets status- as updated by relavanet modules Report dispacth status- If no, Then system should allow the user to take
request for the dispacth.Users with access control
PRM Users – read/write access
Pre – requisites
PRM requires the query from the patients who want to use /have used the hospital services.
Business Process Details Report status to be maintained in the above format.( As perScreen
design) Request no. /LRN No/ DRN no. of investigation Patient details such as Name, Gender & age
For Internal Use Page 60 of 232
MedMantra Software Requirements Specifications ver.0.1
Department – under which the investigation was done Requets status- as updated by relavanet modules(LAB/Radiology) Service name
Report dispacth status- If no, Then system should allow the user to take request for the dispacth.Request for dispacth should have following details
Requetsor name Patient Name Requested report name Address to which the report has to be sent – Emial/Mailing address Date of investigation Service name LRN/DRN NO., UHID or Patient identifier available will be part of the
request Contact details of the caller/patient – Phone no. or E-mail ID Request taken & is sent to the respective department user as
notification/request.
The department will authorize & send sthe report to dispacth section to courier or send it to the customer address as requested
Alternate / Flexibility Options in the Business Process
-NA-
OutputsMessagesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 61 of 232
MedMantra Software Requirements Specifications ver.0.1
3.1.10.6 Tariff Information
Draft UI for Tariff Information
3.1.10.6.1 Business ProcessBusiness process
Description Customer wants information on Tariff of hospital services – The following information needs to be retrieved by the sysytem base don serach criteria
Service ID Service Name Tariff Any other details as required by the Business in future
Users with access control
PRM Users – read/write access
Pre – requisites
PRM requires the query from the patients who want to use /have used the hospital services.
Business Process Details
Tariff search should be based on following criteria Location Patient service Patient Type Agreement
For Internal Use Page 62 of 232
MedMantra Software Requirements Specifications ver.0.1
Billing type Service type Service name.
The following information needs to be retrieved by the sysytem base don serach criteria Service ID Service Name Tariff Any other details as required by the Business in future
If agreement name is told by the customer then only the information can be given correctly or else the PRM user can ask the credit patient to get estimate from the billing department.( Same rule applicable to Estimation details also)
Business Rule- By default the patient service type will be OP only
Alternate / Flexibility Options in the Business Process
-NA-
OutputsMessagesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 63 of 232
MedMantra Software Requirements Specifications ver.0.1
3.2 FEEDBACK & COMPLAINT MANAGEMENTFeedback Handling
This diagram explains about the feedback how it is handled.
Figure : Feedback Handling
3.2.1 Business Process details
Description The Feedback is taken from the patients/attendants & cumulative data is shared with all stake holders. The objective is to record patient/Guest feedback about the hospital services , Arrive at satisfaction rates, Referral Index etc & ANALYSE the trends across the enterprise.
For Internal Use Page 64 of 232
MedMantra Software Requirements Specifications ver.0.1
In Apollo there are multiple source of taking the feedback like Feedback given by the patient in Physical form/paper based feedback
questionnaire Web based feedback – through email Id/ feedback form available on the
website. Kiosk available in patient care areas & lobby areas where it can be captured
should be integrated with PRM – Feedback Feedback form sent as link in the email sent to the patient which can be filled
up & sent back. Mobile/blue tooth application through which the feedback can be captured is also
to be integrated with PRM- feedback.
Hence system should be able to provide an mechanism to integrate all such source of Feedback to provide a common work list(TBD)However the system should manage:
1. Form builder – Feedback questionnaire can be different from location to location. Questinnaire can be categorized into two parts transactional & objective type of questionnaire. Objective questionaaire are similar across the location while the trasactional type of questionnaire is specific to department & location.
2. Logic for analysis- which will define the OUTPUT parameter ( for eg- Net promoter score) for each question & calculate the output parameter based on the parameters defined against the out parameter
Cummulative score Logic can be diffrent3. Delisting the feedback line item from the work list once it is closed
Can serach for a closed item & reopen it if required4. Configuration to Assign the feedback
Set up required for different work areas, Sub areas (& attributes against the sub area.)
Setting up the Action & information groups against the above combinations.
5. Giving options to earmark & divide the complaint /suggestion /compliments against relevant departments (action & Information groups) for a single feedback
6. Complaint Assignment- Configuration to set up different work areas, Sub areas & attributes Configuration to Set up the Action & information groups against the
above combinations7. Complaint cycle Management –
Depending on which problem is related to (people/process/infrastructure etc) complaint cycle is followed.
Complaint cycle is a chain of activities gone through to find & close solution to complaint.
8. Escalation Matrix – After how many hours/days the complaint will be given, escalated if it is closed within agreed timelines (As per SLA”s) therefore measures to close the complaint will be taken up quickly.
9. During the communication with the complainer/customers who have given feedback, the sender should be able to send it through different communication details via SMS, EMAIL, Mail etc. in default texts
For Internal Use Page 65 of 232
MedMantra Software Requirements Specifications ver.0.1
The system should have following capabilities Create /Build a feedback questionnaire location wise- Configurable
feedback questionnaire & Logic for analysis based on each question should be configurable.
Feedback form should be printable against the UHID no.- Every admission/OP file should have feedback form against UHID & particular episode Number against which the feedback can be printed
System should be capable enough to capture the Feedback through following Mechanism
Entered by PRM user based on the manual feedback provided by the patient/attender
System’s feedback form format should support the manual feedback form to capture it through an optical character reader so that there is data integrity is maintained.
Integrated with Kiosk – feedback to be captured into HIS. E-mail – Feedback form link can be sent to the patient email Id after
the discharge. Feedback received through E-mail are captured by the PRM user in
the system. Original E-mail content to be attached to the feedback. Should support the format available in Website.
Work list to review the feedback & to take action on the feedback.
o All PRM user should be able to view the feedback given by a patient against their UHID
o Department HOD will have access to view & also capture the initial action to be taken on the complaints against the department.
o HOD can capture problem identified, Initial action taken & proposed permanent solution for the identified problem.
o The above captured details should be viewable by CRM cello CRM Cell/PRM ADMIN has
o Access to view, update & segregate the feedback into their respective sections depending on the nature of feedback.
o Nature of feedback can be compliment/complaint or suggestion. & also it can be for/against different departments
o System should have capability to register / generate multiple complaint/suggestion/complaints against multiple department against a single feedback. Against feedback ID mutiple case ID can be generated against episode no./patient identifier
o Once an Area/sub area & attribute are selected against relevant nature of feedback it goes to the Action group & Information group department .Action group comprises Head’s dashboard (HOD) & any other department who should be involved in taking action. Information group are members who need to informed (top management)
o The details captured by action group are auto populated & rest of the cycle activities are captured by CRM Cell
o Once complaint is registered, the complaint cycle to be depicted to capture the entire complaint cycle events depending on the what the complaint/problem is related (Human/Process/Infrastructure)
For Internal Use Page 66 of 232
MedMantra Software Requirements Specifications ver.0.1
o Closure & of the complaint- complaint closure option with the CRM cell when required action is taken
Users with access control
PRM Users, All departments
Pre – requisites
The patient/attendant or corporate/customer/referral doctor must avail the services of the hospital directly or indirectly to give feedback.
Business Process Details Process Description
PRM handles the feedbacks received to the hospital. The feedback is collected from Inpatient’s, Outpatient’s or from the patient attendant/visitor to the hospital.
Feedback primarily comes from the feedback form given to patients. Feedback can also come from various other modes i.e. telephone, fax, web,
mail, or directly by patient/attendant. PRM receives an alert from the Wards & Discharge module, whenever a
patient discharge process initiates. PRM should go to collect feedback from patients marked for discharge.
PRM gets the diverted call from the Call management, if the caller wants to give feedback or callcentre also can capture the feedback.
PRM collects feedback forms from the suggestion/Complaint box at ICUs/OTs/Wards/OPDs.
The PRM users must update feedback in the system. The system should be capable of taking input in the format given in the form or in free text (if feedback is through mail/email/phone/etc.
Patient/attendant can enter the feedback in a touch screen kiosk which displays the feedback form format.Integration of Kiosk with PRM feedback is mandatory.
The feedback reports must be accessible by the respective departments and top-level management.
Thanks letters to be sent to all patients who gave positive feedback. The process can be define in few steps
CAPTURING THE FEEDBACK through different Mechanism
Entered by PRM user based on the manual feedback provided by the patient/attender
System’s feedback form format should support the manual feedback form to capture it through an optical character reader so that there is no data & data integrity is also maintained.
Kiosk – feedback to be captured in the same format as in manual form.
E-mail – Feedback form link can be sent to the patient email Id after the discharge.
Should support the format available in Website.
o FEEDBACK MANAGEMENT –
Access to view, update & segregate the feedback into their respective sections depending on the nature of feedback.
For Internal Use Page 67 of 232
MedMantra Software Requirements Specifications ver.0.1
Nature of feedback can be compliment/complaint or suggestion. & also it can for/against different departments
System should have capability to register / generate multiple complaint/suggestion/complaints against multiple department against a single feedback
Once an Area/sub area & attribute are selected against relevant nature of feedback it goes to the Action group & Information group department .Action group comprises Head’s dashboard (HOD) & any other department who should be involved in taking action. Information group are members who need to informed (top management
o ACTION ON FEEDBACK - Action group (Department HOD) will have access to view &
also capture the initial action to be taken on the complaints against the department.
Action group (HOD) can capture problem identified, Initial action taken & proposed permanent solution for the identified problem.
The above captured details should be viewable by CRM cell
o REVIEW& CLOSURE OF THE FEEDBACK
Once complaint is registered, the complaint cycle to be depicted to capture the entire complaint cycle events depending on the what the complaint/problem is related (Human/Process/Infrastructure)
The details captured by action group are auto populated & rest of the cycle activities are captured by CRM Cell
CRM cell closes the complaint cycle when needed action is taken on the complaint
Re-open option is available with the Information group – when ever need arises the complaint can re-opened
o SEND APPROPRIATE COMMUNICATION TO THE PATIENT/CUSTOMERS
Every feedback is acknowledged & appropriate communication sent to the complainer/customers who have given feedback,
The PRM User should be able to send it through different communication details via SMS, EMAIL, Mail etc. in default texts
Business Rules Feedback ID created for each feedback against Each UHID/Episode NO. Multiple Feedback ID’s can be present against each UHID. Episode wise – Multiple feedbacks can be present The feedback reports are sent to the Action & Information groups (respective
departments & top management) once feedback is segregated on daily/ monthly, quarterly basis through e-mails.
The monthly & quarterly feedback report summary will be based on department wise with pie chart, bar graph representation.
The reports are based different Output parameters as decided by the management .for e.g.- NPS- Net promoter score etc
The feedback form is not updatable once saved (except for CRM cell)
For Internal Use Page 68 of 232
MedMantra Software Requirements Specifications ver.0.1
CRM cell will have option to view & update while any other PRM user will only have option to view the feedback once saved.
Feedback work list for each action group/Information group depends on the area& sub area defined.
Re-open option with the information group/top management even after closure.
Configurable Feed back form questionnaire & logic for nalysis
Configurable default messages to be sent to patient & various stake holders
The feedback reports must be accessible by the respective departments and top-level management.
Alternate / Flexibility Options in the Business Process
-NA-
OutputsFeedback Reports are generated based on
Periodic Reports on top complaints in Excel/PPT
Bed to Feedback Capture ratio
Bed to complaint ratio
TAT for complaint redressal (type/department wise)
Top Problems of the month/week
Reports are generated based on
o Complaint Category
o Department wise
o Date wise
o Severity wise
o Priority wise
o No of complaints pending
o Complaints closed
o Complaints reopened by CEO
Graphical and time analysis of feedback received
Messages Alert a message to PRM when patient discharge process initiates.Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-
For Internal Use Page 69 of 232
MedMantra Software Requirements Specifications ver.0.1
Trigger Out -NA-Assumptions -NA-
3.2.2 CAPTURING FEEDBACK
Draft UI of Feedback Form
3.2.2.1 Business Process
Description Feedback through mutiple sources is captured in the feedback formIn Apollo there are multiple source of taking the feedback like
Feedback given by the patient in Physical form/paper based feedback questionnaire
Web based feedback – through email Id/ feedback form available on the website.
Kiosk available in patient care areas & lobby areas where it can be captured Feedback form sent as link in the email sent to the patient which can be filled
up & sent back. Hence system should be able to provide an mechanism to integrate all such source of Feedback to provide a common work list(TBD)
For Internal Use Page 70 of 232
MedMantra Software Requirements Specifications ver.0.1
However the system should manage:1. Form builder – Feedback questionnaire can be different from location to
location.2. Logic for analysis- which will define the OUTPUT parameter ( for eg- Net
promoter score) for each question & calculate the output parameter based on the parameters defined against the out parameter
3. Configuration to Assign the feedback/complaint Set up required for different work areas, Sub areas (& attributes
against the sub area.) Setting up the Action & information groups against the above
combinations.4. Giving options to earmark & divide the complaint /suggestion /compliments
against relevant departments (action & Information groups) for a single feedback
The system should have following capabilities Create /Build a feedback questionnaire location wise- Configurable
feedback questionnaire & Logic for analysis based on each question should be configurable.
Feedback form should be printable against the UHID no.- Every admission/OP file should have feedback form against UHID & particular episode Number against which the feedback can be printed
System should be capable enough to capture the Feedback through following Mechanism
Entered by PRM user based on the manual feedback provided by the patient/attender
System’s feedback form format should support the manual feedback form to capture it through an optical character reader so that there is no data & data integrity is also maintained.
Kiosk – feedback to be captured in the same format as in manual form.
E-mail – Feedback form link can be sent to the patient email Id after the discharge & same once filled will become worklist item in E-HIS
While integrating with website system Should support the format available in Website.
Users with access control
PRM Users, All departments
Pre – requisites
The patient/attendant or corporate/customer/referral doctor must avail the services of the hospital directly or indirectly to give feedback.
Business Process Details Process Description
PRM handles the feedbacks received to the hospital. The feedback is collected from Inpatient’s, Outpatient’s or from the patient attendant.
Feedback primarily comes from the feedback form given to patients.
For Internal Use Page 71 of 232
MedMantra Software Requirements Specifications ver.0.1
Feedback can also come from various other modes i.e. telephone, fax, web, mail, or directly by patient/attendant.
PRM receives an alert from the Wards & Discharge module, whenever a patient discharge process initiates. PRM should go to collect feedback from patients marked for discharge.
PRM gets the diverted call from the Call management, if the caller wants to give feedback. Or
If business reuqires call centre/PRM user who received the call captures the feedback
PRM collects feedback forms from the suggestion/Complaint box at ICUs/OTs/Wards/OPDs.
The PRM users must update feedback in the system. ( feedback is through mail/email/phone/etc.
Patient/attendant can enter the feedback in a touch screen kiosk which displays the feedback form format.
The feedback reports must be accessible by the respective departments and top-level management.
Feedback Questionairre contains
Patient details –UHID/Patient identifier,Name, gender, Nationality,Mother toungue& Location
Feedback details- Person who gave the feedback – His/Her name, Relation ship with the patient,,Source of feedback (LOV to be maintained in dropdown)
Question, Scale on which it is rated , Range of scale Vs category ( Configurable)Along with the reason for rating the particular scale.
Service star details- Person who has provided execellent services in the view of the patient are service star, Name of service star & department to be captured Previous service details are auto populated from data base based on UHID.
o Details to include
Episode No. Service utilized Date Feedback ID & feedback given last time can also be populated to add
context to the present complaint. Feedback ID generated Once form is captured then case ID’s can be generated
o Case ID creation
Nature of feedback is selected The text box captures the relavent complaint portion from the main
field Relavent Area,Sub area & attributes are selectedbased on complaint
details Also Information & action group are selected . Case ID generated Mutiple case Id’s can be generated for a single feedback. But the Feed back ID will be unique for the episode (patient identifier)
For Internal Use Page 72 of 232
MedMantra Software Requirements Specifications ver.0.1
Currently the Feedback form consists of few question whose out come is measured in NPS(Net promoter score)
While capturing the defined scale range will automatically get stored as defined category ( for that range)
Business Rules Feedback ID created for each feedback against Each UHID/Episode NO. Configurable questionnaire along with logicf or analysing the outcome Mutilple Case ID’s gainst a Feedback ID which is unique to the episode(patient
identifier) Mutiple FeedbackID’s episode wise to b elinke dto UHID. Configurable buckets for area/sub area/attributes & concerned action,
Information group.
Alternate / Flexibility Options in the Business Process
-NA-
Feedback ID generated Case ID’s generated against Feedback ID
Messages Alert a message to PRM when patient discharge process initiates.Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 73 of 232
MedMantra Software Requirements Specifications ver.0.1
3.2.3 Feedback managment
Draft UI of View Feedback
3.2.3.1 Business Process
Description However the system should manage:1. Update option for updating the Feedback details
ADD Case ID’s Delete Case ID’s while the original feedback remains same
only Case creation text, Nature ,segregation /bucketing can be updated
2. Configuration to Assign the feedback/complaint Configuration required for different work areas, Sub areas (&
attributes against the sub area.)
For Internal Use Page 74 of 232
MedMantra Software Requirements Specifications ver.0.1
Setting up the Action & information groups against the above combinations.
3. Giving options to earmark & divide the complaint /suggestion /compliments against relevant departments (action & Information groups) for a single feedback
The system should have following capabilities System should be capable enough to capture the Feedback through
following Mechanism Entered by PRM user based on the manual feedback provided by
the patient/attender Entered through other sources such as E-mail/KIOSk or another
mechanism of capturing the feedback. Post visit Ip patients feedback to be part of the feedback worklist .
Users with access control
PRM Users, All departments
Pre – requisites
Feedback captured
Business Process Details Process Description
PRM handles the feedbacks received to the hospital. The feedback is collected from Inpatient’s, Outpatient’s or from the patient attendant.
View Feed back form-
The CRM Cell views the feedback form & then select/modifies the inputs if required, except the main rating selected & comments from patient captured
a) Selects the severity/ Type of letter to be sent (Thank you/apology)
b) Broadly classifies the Problem related to -people/process/Infrastructure.
c) Able to split the complaint/suggestion/ compliment against relevant area/sub area/attribute / action & information groups.
d) After the action group/ Information group are selected in case of a complaint (for which nature of feedback is complaint) the complaints will go their inbox (e- mail) also to their individual dashboard
Access to view, update & segregate the feedback into their respective sections depending on the nature of feedback.
Nature of feedback can be compliment/complaint or suggestion. & also it can for/against different departments
System should have capability to register / generate multiple complaint/suggestion/complaints against multiple department against a single feedback
Once an Area/sub area & attribute are selected against relevant nature of feedback it goes to the Action group & Information group department .Action group comprises Head’s dashboard (HOD) & any other department who should be involved in taking
For Internal Use Page 75 of 232
MedMantra Software Requirements Specifications ver.0.1
action. Information group are members who need to informed (top management
Verify Option to be provided . Once verified is checked then feedback details hit the respective dashboard
Business Rules Verify Option to be provided . Once verified is checked then feedback details
hitthe respective dashboard Complimets & suggestion get auto closed once verfied by PRM Admin/CRM
cell / Customer intelligence team( Role can be named as any of the above , bUt it isonly ine role)
Complaints should hit the respective HOD dash board for complaint resolution Case ID details get updated /verified.
Alternate / Flexibility Options in the Business Process
-NA-
Output Case ID’s viewed updated- Addition /Deletion against Feedback ID & verified
Messages E-mail to both action & information group members on the complaint raised.Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 76 of 232
MedMantra Software Requirements Specifications ver.0.1
3.2.4 Action on Feedback
Draft UI for ADMIN Dashboard
3.2.4.1 Business Process
Description System displays all the compliments/suggestions/ complaints assigned to the user (owner of the complaint).
System should be able to manage:
User selects the complaint. System displays the details about the complaints. User enters the details of action taken by him. User updates the status. User saves the data. System displays the full trail of action taken on the complaint from the date of
complaint registration. As per complaint cycle depending on what the problem related to.
Users with access control
PRM Users, All departments
For Internal Use Page 77 of 232
MedMantra Software Requirements Specifications ver.0.1
Pre – requisites
Feedback captured
Business Process Details
Complaint related departments Head of the deaprtment will view the complaint details& takes neccesary action required . if any permanent resolution is proposed the request goes to CEO/VP who will approve necessary budget to implement the solution
The following attributes should be viewable feedback details- View original feedback complaint details- complaint text
Option to capture the problem identified, intial action take, Proposed permanent resolution
a) HOD enters the initial action taken on problem identified & proposed permanent solution.
b) This complaint information is reviewed & closed by CRM cell.
c) In case if complaint has to reviewed again & further action required then complete the complaint cycle is followed.
d) TOP complaints for the month will be reviewed & then complaint cycle has to be followed for such cases.
e) Notification & reminders for complaints which are not closed in time.( as per SLA’s) as per configuration for escalations.
Business rule The complaints after login, basing on the department the complaints should
available to the HOD of the concerned department.
The complaint has to be sent to the HOD of the departments and the HOD in turn can assign to his/her sub-ordinates to solve the complaint.
For auto escalation the ‘time limit’ and ‘escalation to’ should be customizable basing on priorities (high, medium, low).
The owner of the complaint related information should be automatically send to the Inbox for visibility.
The HOD’s of departments can access the report on complaints of his/her respective department.
Top-level management has access rights to the complaints and reports.
Auto generated E-mail for every complaint raised & closed to all Action & information group members
Auto generated reports can be sent to the management weekly/bi-weekly/monthly/quarterly/half-yearly/annually. This can be customizable and date & time should be customizable.
For Internal Use Page 78 of 232
MedMantra Software Requirements Specifications ver.0.1
Note- if the business decided to give acess to HOD to close the complaint then complaint cycle attributes will be captured by HOD
Alternate / Flexibility Options in the Business Process
-NA-
Output Complaint cycle intiated & closed Complaint cycle closed if required
Messages E-mail to both action & information group members on the complaint raised.
Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.2.5 Review of Action taken on Complaint
Draft UI for Admin – Action (pop-up)
3.2.5.1 Business ProcessBusiness Process Details
For Internal Use Page 79 of 232
MedMantra Software Requirements Specifications ver.0.1
Description System displays all the complaints assigned to the user (owner of the complaint).
System should be able to manage:1. Complaint cycle Management –
Depending on which problem is related to (people/process/infrastructure etc) complaint cycle is followed.
Display & capture Complaint cycle is a chain of activities gone through to find & close solution to complaint.
2. Escalation Matrix – After how many hours/days the complaint will be given, escalated if it is closed within agreed timelines (As per SLA”s) therefore measures to close the complaint will be taken up quickly.
Work list to review the feedback & to take action on the feedback.o Once complaint is registered, the complaint cycle to be depicted to
capture the entire complaint cycle events depending on the what the complaint/problem is related (Human/Process/Infrastructure)
o Closure & of the complaint- complaint closure option with the CRM cell when required action is taken
.Re-Open option for PRm Admin/Vp/CEO/Top managment– If the complaint has to be re-opend
System displays the full trail of action taken on the complaint from the date of complaint registration. As per complaint cycle depending on what the problem related to.
Users with access control
PRM Users, All departments
Pre – requisites
Feedback captured
Business Process Details
Customer intelligence team. PRM admin, CEO/VP will have separate dashboard where they can view
The following attributes should be viewable feedback details- View original feedback complaint details- complaint text Aggainst UHID- All the Feedbacks received Episode wise to be
viewed Aging of the case to be viewed on the dashboard TAT times for each complaint closure will have to
displayeda) The CRM or Admin Dashboard will show all the feedback across
departments. TOP complaints for the month will be reviewed & then complaint cycle has to be followed for such cases. complaint cycle for person related/process related
b) In Person related problems HR receives the complaint details along with HOD. A copy of the complaint goes into Employee file. Linked to KRA( which can assessed during performance appraisal)
c) If Medical employee is included in the complaint( Doctors) then the
For Internal Use Page 80 of 232
MedMantra Software Requirements Specifications ver.0.1
Complaints reaches the medical super indent along with quality cell.
d) In process related problems the HOD proposes the solution which are approved by top management( i.e. VP /CEO etc) . All requirements to implement the solution (financial/non- financial needs are identified * proposed for approval.
e) After the approval the proposed solution implemented & assessed for its efficacy.
f) If satisfied the complaint is closed. or reviewed again for further scope of improvement.
Business rule Re-open option is available to top management/PRM admin if the closure of HOD
is not adequate. Total feedback against UHID along with episode wise – Case ID’s & Feedback ID’s
to be viewed by top management./Prm admin.
Note- if the business decided to give acess to HOD to close the complaint then complaint cycle attributes will be captured by HOD
Alternate / Flexibility Options in the Business Process
-NA-
Output Complaint cycle Closed Complaint cycle re-opened if required
Messages E-mail to both action & information group members on the complaint closed.Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 81 of 232
MedMantra Software Requirements Specifications ver.0.1
3.2.6 SEND APPROPRIATE COMMUNICATION TO THE CUSTOMER
Draft UI For PRM (Feedback cell ) Executive Dashboard
3.2.6.1 Business Process
Description Every feedback is acknowledged & appropriate communication sent to the complainer/customers who have given feedback,
The PRM User should be able to send it through different communication details via SMS, EMAIL, Mail etc. in default texts
Sysytem should be able to manage Bulk Print option to print default text for various types of letters to be sent to the
patient/refferal doctor Configurable default text to be sent to patient & refferal doctor through various
channels (e-mail/SMS also) Configurable message to refferal doctor/refferal organisation also through various
For Internal Use Page 82 of 232
MedMantra Software Requirements Specifications ver.0.1
channels Option to send Thanks you letter to service stars of the department through various
channelsUsers with access control
PRM Users, All departments
Pre – requisites
Feedback captured
Business Process Details
Executives in the department will send the letter through post or e-mail to the patient, refferal doctor/ servcie star
The Dashboard contains the following attributes Feedback ID Type ofletter to be sent Patient identifier Patient name Nature of feedback – case Id wise Complaint On
a) Option to capture the feedback – link to be provided
Business rule Bulk Print option to print default text for various types of letters to be sent to the
patient/refferal doctor Configurable default text to be sent to patient & refferal doctor through various
channels (e-mail/SMS also) Configurable message to refferal doctor/refferal organisation also through various
channels Option to send Thanks you letter to service stars of the department through various
channels.Note- if the business decided to add any new type of letter to be sent then it should be configurable.
Alternate / Flexibility Options in the Business Process
-NA-
Output Appropriate commincation – letter /Email sent to patient & refferal doctor & service star
MessagesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 83 of 232
MedMantra Software Requirements Specifications ver.0.1
3.2.7 Input Attributes
Attribute Name Attribute Description
Nature of Data Element (MOC)
Data Type
Length /
Size
List Of Values/Code Set
Conditions
Logic
Validation
Operations (I/D/U/Q)
Originating
Service/Device
Remarks
Feedback DateDate on which feedback is given M DateTime
Auto System generated date which can also be updated Q
System generated date
UHID Patient UHID M Varchar 10 Q Registration
Title Title M Varchar 30 Title 07 Q Registration
First Name Patients First Name O Varchar 50 Q Registrati
on
Middle Name Patients Middle Name O Varchar 50 Q Registrati
on
Last Name Patients Last Name O Varchar 50 Q Registrati
on
RelationRelationship with the patient M Varchar 50 Relationship
25 Q
feed backer Name
feed backer Name C Varchar 50
If relation is not self
I/D/U/Q
Patient CategoryType of patient category M Varchar 30
Patient Category 27 Q
Address feed backers Address O Varchar 100 I/D/U/Q
Contact NumberContact Number of the feed backer
O Number 15 I/D/U/Q
Date of visitDate of visit to the hospital M Number I/D/U/Q
EmailEmail of the feed backer O Varchar 50 I/D/U/Q
Department name
Name of the Department from which feedback is collected
O Varchar 50 I/D/U/Q
Source of feedback
From where the feedback is received M Varchar 20
Nature of feedback
What is nature of the feedback M Varchar 20
Patient Location
Physcial location of patient in hospital, Floor Wrad name M Varchar 100
Gender Male or female M Varchar 10 Registration
For Internal Use Page 84 of 232
MedMantra Software Requirements Specifications ver.0.1
Mother toungueLanguage of the
patinet O Varchar 20 Registration
Servcie star Employee name O Varchar 50
Serive star departmnet
Department LOV’s C Varchar 50
Department LOV =
How satisfied are you with the service s provided by the hospital?
Rated on scale of 0 to 10 M Varchar 250
Configurable through master
Would u like to reccomend
Rated on scale of 0 to 10 M Varchar 250
Configurable through master
Rating scale ) to Rating sclae M
Check z
Please let us know the reason for rating Text O Varchar 250
Configurable through master
Please let us know the reason for rating & recoomeding it to your friends/family Text O Varchar 250
Configurable through master
Would you like to get updates on subjects like health & Lifestyle Yes or no O Yes or no
If yes , Email Id C Varchar 50
3.2.8 Complaint Monitoring sheetComplaint Monitoring Sheet: for process & Person related Failure
Complaint Track Sheet for Person
ISSUE/ PROBLEM
ACTION TAKEN BY HOD
ACTION TAKEN BY
HR
HOD INFORMED
ABT ACTION
TAKEN BY HR
ALLOCATED PERIOD
TO SUPERVISE
PERSON TO
SUPERVISE
FURTHER COMPLAINTS
ACTION
TAKEN IF YES
PERFORMANCE
APPRAISAL
O
Complaint Track Sheet for ProcessISSUE
/ PROB
ANALYSI
MODIFICATIO
N
EXPENDITURE ON MODIFIC
APPROVAL OF
EXPENDIT
INFORMATION TO
STAFF ABT
SUPERVISION
FURTHER
COMPL
IMPACT ON
REVENU
DECISION
O
For Internal Use Page 85 of 232
MedMantra Software Requirements Specifications ver.0.1
LEM S OF PROCESS
ATION URE BY HEAD
OPERATIONS
CHANGE AINTS E
3.3 Counseling
The Patient/Attendants are counseled about the treatment, precautions to be taken before and after the treatment. The counseling is done for
ICU’s/Emergency/Wards/OPDBlood donorCancer CasesTransplant CasesPost Surgical Cases (rehab counseling)End of life careCommunicable diseasesMass counseling Financial aid services GriefOrgan donor
The Counseling department gets an alert whenever a patient is admitted in the emergency, ICU’s or doctor/nurse raises a request for counseling. Alerts also need to be sent when a death is declared.
Surgical patients – once a surgery request is raised & request completed the information & status to be depicted for the patient counselling pre & post surgery
Counseling the patient/attendantThis flow diagram explains about the Counseling process
For Internal Use Page 86 of 232
MedMantra Software Requirements Specifications ver.0.1
Figure : Counseling of Patients/Attendants
For Internal Use Page 87 of 232
MedMantra Software Requirements Specifications ver.0.1
Draft UI For Counseling Dashboard
3.3.1 Business Process Details Description
Social worker cousell each & every patient who have come to hospital as Inpatient or through emergency . They are part of interdisciplinary group of the hospital who will talk to patient in the daily rounds of the patient.care areas.
Apart from the above , special Need of counseling to the patient is identified by Doctor or Nurse or Ward SecretaryPatient’s who needs counseling are scheduled through appointments & scheduling module.Patient/attendant is counseled according to the schedule.
Sysytem should manage :
Worklist of all inpatient admitted through emergency /ICUor directly through wards are couselled every day depending on their need Worklist of appointment received against the couselling department in appointment & scheduling module. Hightlight all patients in emergency both (OP/IP) / ICU Provision for capturing mass couselling details Provision for capturing special forums/ discussion conducted for a specail group of patients such as breast cance patients etc. Automatic message/alert to the cousellors for all visits to the emergency(OP/IP) Configuration at location level for mapping the social worker to patient care
For Internal Use Page 88 of 232
MedMantra Software Requirements Specifications ver.0.1
areas/location. For e.g Mr.ABC to 1st & 2 nd floor etcUsers with access control
PRM Users, Counseling department, Wards, Doctors
Pre – requisites
Patient arrives at hospital for treatment.Or Need for counseling to Patient/Attendant is identified by counseling department or initiated by the Doctor/Nurse/Ward Secretary.
Business Process Details Process Description
Worklist will have all Inpatients currently in the hospital Emmegency & ICU patient are highlighted Emegrency to Ip convertion are highlighted
The dashboard will have following attributes
Patient Identifier Patient Name Ward Diagnosis Consultant Name Attended By- Cousellor name as captured in couselling record’\ Date & time of cosuelling Requires financial assitance –yes or no as capture dfrom couselling record Requires another couselling - yes or no as capture dfrom couselling record If yes- next scheduled date & time as capture dfrom the couselling form Would be part of health club- Yes or no as captured from couselling record. Status- Can updated by cousellors from time to time Once patient discharged the work list is delisted. The Doctor/Nurse/Ward Secretary sends an alert, to the counseling department about the need of counseling to the patient.
The counselor fixes the appointment for counseling the patient/Attendant depending upon the counseling needed to them.
Counseling are of different types. Some of them are
o Cancer cases
o Transplant cases
o Post Surgical cases
o Communicable diseases
o Referral service
o Mass counseling
o Financial aid service
o End of life care
o Grief
For Internal Use Page 89 of 232
MedMantra Software Requirements Specifications ver.0.1
o Blood donor counseling
o Organ donor counseling
Counselor collects the pre-requisites document from helpdesk to counsel. Counselor counsels the patient/attendant. The Counselor updates the system about the counseling and Type of support provided. Counseling is done to the chronic diseased patients (cancer, Diabetic …) repeatedly. For Mass Counseling - a group of patients/attendants is counseled for a particular disease (cancer, Diabetic, Cardio).
o Appointment is fixed for Mass Counseling.
o Group of patients/attendants is called for counseling.
o Group is informed about Date & time, venue, Counselor.
o Counseling is done.
For Financial aid service –o Doctor/Nurse/Ward Secretary sends an alert to the Counseling department, for financial aid to the patients who are economically backward.o Counselor identifies the patients who need the financial aid service.o Appointment is fixed.
o Counselor collects the pre-requisite documents for financial aid.
o Counselor provides necessary information, financial letter and bill estimate.o The patient is directed to the welfare organizations/Societies/ Government organizations for financial aid.o For financial aid service the patient must hold
o Green Card (or other card stating BPL status)
o Low Income Certificate
For End of life care counseling -o The Counseling department gets the list of patients who are at end of life from Doctor’s, Patient’s record module.o The Counselor fixes the appointment.
o The Counselor visits the patient and counsels the patient.
o The Counselor provides services to the patient like
o Providing lawyer for settling assets.
o Bringing Priest/Pastor o The Counselor counsels the attendants and consoles them
Couselling Record
Each individual patient is couselled as per the requirement a reocrd is maintained til he check out of the hospital
For Internal Use Page 90 of 232
MedMantra Software Requirements Specifications ver.0.1
Each time – The date & time are recordedo Typeof couselling done for that sessiono The couselling needs assesed & appropriate action taken
Coselling needs – Educational/ psyhological are marked Eachof the below needs are assesed & ticked ye s or No.
Educational needs Financial needs Financial assistance required Support for family & children Cultural/religious barriers Referral for Community centre required Prosthetic requirements Other requirements
Appropriate action taken according to the needs assesmento Next couselling if required is also scheduled.- date & time of next schedule
dispalyedin dashboardo Once a record is saved. It should display in the history record of couselling
record of that particular patient.& corresponding record should be available as alink.
A part from individual couselling, Mass couselling also happens where all the patient relatives are couselled ingeneral.
Provision to mark all patients who have attended the mass counselling Provision to capture the objective/reason for mass couselling & remarks can be included.
Periodically patient get togethers through a common progarrmae/forum such as breast cancer programme etc are conducted by the social workers department.
Social workers department needs provision to note the event details, Purpose, No. of people/patients attended it. Also option to upload the names of people attending the forum discussions etc.
Business Rules The counseling user should have access to the patient record (EMR), if it is under rules of HIPAA. The Appointment fixing/re-scheduling shall be accessible to the counseling users. For financial aid service the patient must hold
o Green Card
o Low Income Certificate
Or it can be customizableo Once a record is saved. It should display in the history record of couselling record of that particular patient.& corresponding record should be available as alinko For surgical patients- Status from OT module to updated on the dashboard – another column to be added to know the surgery request status of the patient. Request raised, confirmed & completed status to be updated from OT module.o Alerts also need to be sent when a death is declared.
o Surgical patients – once a surgery request is raised & request completed the information & status to be depicted for the counseling patient pre & post surgery
Alternate / Flexibility
-NA-
For Internal Use Page 91 of 232
MedMantra Software Requirements Specifications ver.0.1
Options in the Business ProcessOutputs Reports are generated on
o List of patients/Attendants counseled on date-wise
o List of patients/Attendants counseled on department wise
Messages A message is received whenever counseling is required to the patient from Doctors/Ward Secretary/Nurse.The Counseling department gets an alert whenever a patient is admitted in the emergency, ICU’s.
Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In Counseling process is triggered or initiated by doctors/ward secretary.Trigger Out -NA-Assumptions -NA-
3.3.1.1 Input /Attributes
Attribute Name Attribute Description
Nature of Data
Element (MOC)
Conditions Logic
Data Type
Length / Size
List Of Values/Code Set
Default Value
Capture Method (T/TA/C/R/D/L/LB
L)
Operations (I/D/U/Q)
Originating Service/Device Remarks
UHID Patient UHID M Varchar 10 T Q Registration
Title Title M Varchar 30 Title 07 Mr. D Q Registration
First Name Patients First Name M Varchar 50 T Q Registration
Middle Name Patients Middle Name O Varchar 50 T Q Registration
Last Name Patients Last Name M Varchar 50 T Q Registration Appointment Date & Time
Appointment Date & Time M DateTi
me T U/Q Appointments
Preferred Mode of Contact
Mode of Contact preferred by the patient M Varchar 50 Mode of
contact 08Telephone D Q Registration
Contact Number Contact Number of the patient C
If preferred mode of
contact is telephone
Number 15 T Q
Address Patients Address C
If preferred mode of
contact is snail mail
Varchar 100 T Q
Religion Religion of the patient O Varchar 30 Religion 03 D Q
Marital Status Marital Status of the patient M Varchar 30 Marital
Status 02 D Q
For Internal Use Page 92 of 232
MedMantra Software Requirements Specifications ver.0.1
Family Income Income of the patient family C
For Financial aid, Income must be captured
Number 15 T Q
Type of cousellin grequiredrequired
Type of support required to the patient
M Varchar 50 Type of couselling D U/Q
Couselling needs Carious needs of couselling M Varchar 50
Couselling Needs T I/D/U/Q
Name of the Cousellor
Name of the patient interviewee
M Varchar 50 T I/D/U/Q
Relation of the interviewee to the patient
Interviewee Relationship with the patient
M Varchar 50 Relationship 17 D U/Q
Patient Location type
Patient location in the hospital C Varchar 50 Location 18 D Q
Counseled Patient is counseled M Varchar 50 Decision 04 D U/Q
Type of counselingType of counseling provided to the patient
M Varchar 50 Counseling 19 D U/Q
Services provided Service provided to the patient O Varchar 50 T I/D/U/Q
Venue Place of counseling M Varchar 50 T I/D/U/Q
This venue details are intimated to the patient/attendant for mass counseling
Sero-positive details
Sero-positive details for blood donor counseling
C
For blood donor
counseling, it is
mandatory
Varchar 50 T Q
Bed Number Bed Number of the patient C
For Inpatients
the Bed No is
mandatory
Varchar 50 T Q
Ward Name Ward Name of the patient staying C
For Inpatients the Ward name is
mandatory
Varchar 50
T Q
Attendant name
Patient Attendant name C
In case death of patient
Varchar 50
T Q
Attendant Contact Number
Attendant contact number C
In case death of patient
Varchar 50
T Q
Reason for death Reason for death of patient C
In case death of patient
Varchar 100
T Q
Remarks Remarks if any O Varchar 200 TA Q
Process Checklists
S. No
Check list
Code
Check list
Name
Description
Triggering Event
Check Items
Business Rules for Generation
-NA-
For Internal Use Page 93 of 232
MedMantra Software Requirements Specifications ver.0.1
Alerts / Reminders / Notifications
Sr. NoRequest Code Request Name Time LimitAction Required
Alert MessageNotify UserNotify mechanism
Remarks
-NA-
3.3.2 Blood Donor CounselingThis flow diagram explains about the blood donor Counseling process
For Internal Use Page 94 of 232
MedMantra Software Requirements Specifications ver.0.1
Figure 3 : Blood donor counseling
3.3.2.1 Business Process Details
For Internal Use Page 95 of 232
MedMantra Software Requirements Specifications ver.0.1
Description The blood donor who has donated the blood is counseled, if found positive.Users with access control
PRM Users, Counseling department, Blood Bank Users
Pre – requisites
Blood donor information should present at blood bank. Counseling is done for those who have tested positive.
Business Process Details Process Description
Blood donor arrives at hospital and donates the blood. The blood sample of donor is tested within the blood bank.
If the sample is found sero-positive, then an alert is sent to the Counseling department.
The counseling team gets an alert when the blood donor needs counseling to donate blood.
The counseling cell calls the donor and fixes the appointment.
The Counseling cell counsels the donor and suggests alternates if necessary.
The Counselor may also refer to any welfare organizations/foundation, if the service is not available in the hospital.
Business Rules The counseling cell calls the donor and fixes the appointment. PRM/Call Management Team also can call the patient/donor for fixing the
appointment for counseling. The Counseling is done by the Counseling team member. Doctor can also do counseling to the patient.
Alternate / Flexibility Options in the Business Process
-NA-
OutputsReports are generated
o The list of blood donors who is undergoing treatment in our hospital.
o The lists of donors who are referred to welfare organizations.
Messages A Report is received to the PRM when a blood donor or patient is found with sero-positive.
Exception handling
-NA-
For Internal Use Page 96 of 232
MedMantra Software Requirements Specifications ver.0.1
Error Reporting
-NA-
Scheduling -NA-Trigger In Counseling process is initiated from blood bankTrigger Out -NA-Assumptions -NA-
3.3.2.2 Input Attributes
Attribute Name Attribute DescriptionNature of
Data Element (MOC)
Conditions Logic Data Type Length /
Size
List Of Values/Code Set
Capture Method (T/TA/C/R/D/L/L
BL)
Remarks
UHID Patient UHID M Varchar 10 T
Title Title M Varchar 30 Title 07 D
First Name Patients First Name M Varchar 50 T Middle Name Patients Middle Name O Varchar 50 T Last Name Patients Last Name M Varchar 50 T Appointment Date & Time
Appointment Date & Time M DateTime T
Preferred Mode of Contact
Mode of Contact preferred by the patient M Varchar 50
Mode of contact 08
D
Contact Number Contact Number of the patient C
If preferred mode of
contact is telephone
Number 15 T
Address Patients Address C
If preferred mode of
contact is snail mail
Varchar 100 T
Religion Religion of the patient O Varchar 30 Religion 03 D
Marital Status Marital Status of the patient M Varchar 30
Marital Status 02
D
Family Income Income of the patient family C
For Financial aid, Income must be captured
Number 15 T
Type of support required
Type of support required to the patient M Varchar 50 Support
16 D
Type of support provided
Type of support provided to the patient M Varchar 50
Support 16 T
Name of the interviewee
Name of the patient interviewee M Number 50 T
Relation of the interviewee to the patient
Interviewee Relationship with the patient
M Varchar 50 Relationship 17 D
Patient Location typePatient location in the hospital C Varchar 50 Location
18 D
Counseled Patient is counseled M Varchar 50 Decision D
For Internal Use Page 97 of 232
MedMantra Software Requirements Specifications ver.0.1
04
Type of counseling Type of counseling provided to the patient TBD Varchar 50 Counseli
ng 19 D
Services provided Service provided to the patient TBD Varchar 50 T
Venue Place of counseling M Varchar 50 T
Sero-positive details Sero-positive details for blood donor counseling C
For blood donor
counseling, it is mandatory
Varchar 50 T
Attendant namePatient Attendant name C
In case death of patient
Varchar 50
T
Attendant Contact Number
Attendant contact number C
In case death of patient
Varchar 50
T
Remarks Remarks if any O Varchar 200 TA
3.3.3 Counseling the grief
This flow diagram explains about the counseling the attendants of the deceased patient.
Figure : Counseling the Grief
For Internal Use Page 98 of 232
MedMantra Software Requirements Specifications ver.0.1
3.3.3.1 Business Process DetailsDescription Counseling is done to the Attendants of the patient who was deceasedUsers with access control
Doctors, Registration, Counseling department
Pre – requisites
When the patient is deceased.
Business Process Details Process Description
An alert is received whenever a patient who is undergoing treatment or admitted in the Emergency expires.
The patient bed no, ward name, patient name details are present in the alert, which are accessed from Registration & A&T module.
The Counselor goes to the place where the Attendants of the patient deceased are present.
The Counselor conveys the condolence and counsels the Attendants. The Counselor updates the information about the counseling in the system.
Business Rules Counseling the grief can be done by the Doctor/Ward secretary/Nurse at the
wards.
Alternate / Flexibility Options in the Business Process
-N-
Outputs Reports are generatedo Number of deaths occurred in a day/month/year
o Number of deaths occurred due to a particular disease (Health problem)
o Number of deceased in OT/Wards/ICU’s
Messages An alert can be received from Registration/Wards/Doctors/PATIENT RECORD when a patient is deceased.
Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In When patient is deceased then an alert is received to the counseling department.
Trigger Out -NA-Assumptions -NA-
For Internal Use Page 99 of 232
MedMantra Software Requirements Specifications ver.0.1
3.3.3.2 Input/Attributes
ribute Name Attribute Description
Nature of Data Element (MOC)
Conditions Logic Data Type
Length /
Size
List Of Values/Code Set
Originating
Service/Device
Remarks
UHID Patient UHID M Varchar 10 Registration
Title Title M Varchar 30 Title 07 Registration
First Name Patients First Name M Varchar 50 Registration
Middle Name Patients Middle Name O Varchar 50 Registratio
n
Last Name Patients Last Name M Varchar 50 Registration
Religion Religion of the patient O Varchar 30 Religion 03
Marital Status Marital Status of the patient M Varchar 30 Marital Status
02
Type of support required
Type of support required to the patient
M Varchar 50 Support 16
Type of support provided
Type of support provided to the patient M Varchar 50
Support 16
Name of the interviewee
Name of the patient interviewee M Number 50
Relation of the interviewee to the patient
Interviewee Relationship with the patient
M Varchar 50 Relationship 17
Patient Location type
Patient location in the hospital C Varchar 50 Location 18
Counseled Patient is counseled M Varchar 50 Decision 04
Type of counseling
Type of counseling provided to the patient
TBD Varchar 50 Counseling 19
Bed Number Bed Number of the patient C
For Inpatients the
Bed No is
mandatory
Varchar 50
Ward Name Ward Name of the patient staying
C For Inpatients the Ward name
is
Varchar 50
For Internal Use Page 100 of 232
MedMantra Software Requirements Specifications ver.0.1
mandatory
Attendant name
Patient Attendant name C
In case of patient death
Varchar 50
Attendant Contact Number
Attendant contact number C
In case death
of patient
Varchar 50
Reason for death Reason for death of patient C
In case death
of patient
Varchar 100
Remarks Remarks if any O Varchar 200
Process Checklists
S. No
Check list
Code
Check list
Name
Description
Triggering Event
Check Items
Business Rules for Generation
-NA-
Alerts / Reminders / Notifications
Sr. NoRequest Code Request Name Time LimitAction Required
Alert MessageNotify UserNotify mechanism
Remarks
-NA-
For Internal Use Page 101 of 232
MedMantra Software Requirements Specifications ver.0.1
3.4 Disease Management ProgramThis flow diagram explains about the Disease Management Program process.
Figure : Disease Management Program
For Internal Use Page 102 of 232
MedMantra Software Requirements Specifications ver.0.1
3.4.1 Business Process DetailsDescription Patient arrives hospital, consults doctor, undergoes investigations and chronic
disease is identified.
Diasease programme management are programmed desinged for chronic ill patient . These patients visits are usually planned & services can also defined during each visit & bill is paid against the package which has planned visit details.
System should be capable ofo Setting up the programme definition intermso Worklist generated through serach criteria – Auto generated(based on patients
falling under the applicable criteria)o Also new worklist item can be created by added the patient UHId aggainst
the programme.o Once a worklist is created
o The following actions items would be there for each worklist item Couselling about the programme Assesment through questionnaire particular to the
(forms )programme(Configurable) location wise. Risk assessment based on quetsionnaire(Logic defined in the
questionnaire to aarive at conclusion- configurable) To be integrated with DMP software for predictive analysis. Information related DMP patient collected through contact
centre software ( such as RBS value, BP value etc) are to be integrated with patient record & displayed to doctor through patient snapshot summary
Enroll patient to programme- UHID is now linked to programme ID On enrollment the system asks for schedulable date of visit under
the programme- dates scheduled System sends out automatic messages to the patient about their
visit/appointment (refer to appoint reminder ) Bulk deposit – is shown agaginst the services raised during the
visits. – Provison to view & raise the services for the patient before x days of their next visit after confirmation from the patient.
Users with access control
PRM Users, DMP Users
Pre – requisites
Patient is a registered patient and chronic diseased patient is identified.
Business Process Details Process Description
o Setting up the programme definition intermso Programme valid dateso Programme nameo Programme locationo Programme ownero Applicable populationo No of visits to be scheduled under the programme o Services aggainst each programme are also mappedo Enrolled patient Worklist generated based patient added to the
programme, converted from prospective list.o Also new worklist item can be created by added the patient UHID aggainst
the programme.
For Internal Use Page 103 of 232
MedMantra Software Requirements Specifications ver.0.1
o A prospective worklist is created – through auto generated list from the set criteria of programme definition or the from patient activity check list( refer to patient activity checklist) or Auto generated(also based on patients falling under the applicable criteria)
oo The following actions items would be there for each worklist item
Couselling about the programme Assesment through questionnaire particular to the
programme(Configurable) Risk assessment based on quetsionnaire(Logic defined in the
questionnaire to aarive at conclusion- configurable) Enroll patient to programme- UHID is now linked to programme ID On enrollment the system asks for schedulable date of visit under
the programme- dates scheduled System sends out automatic messages to the patient about their
visit/appointment (refer to appoint reminder )o Bulk deposit – is shown agaginst the services raised during the visits. Patients gets
bill for each visit separetley along with service details.
DMP gets a daily/weekly report of chronic diseased patients from the Patient Record along with contact details such as phone number /E-mail.
If patient is In-patient then, the DMP team visits the In-patient.
DMP fixes the appointment for DMP counseling by accessing the Appointment module/ can use DMP calender.
If patient is not In-patient then, the DMP team calls the patient.
DMP team informs about the Disease Management Program and fixes the appointment according to the patient convenient date & time.
Patient comes to the DMP department on the appointment time.
DMP counsels the patient who is suffering from the chronic disease.
If patient is suffering from Cardiac, then the Patient is advised to undergo Cardio vascular Program (CVD)
If patient is suffering from Asthma, then the patient is advised to undergo Asthma program (Breath Easy).
For other chronic diseases, information is provided according to the diseases.
Patient is suggested to change life style.
Whenever group-counseling program is planned, it is informed to that particular chronic diseased patient.
Counselled by the doctor/cousellor (couselling forms to be made configurable location wise & specialty wise.
Business Rules
For Internal Use Page 104 of 232
MedMantra Software Requirements Specifications ver.0.1
Worklist for enrolled & prospective list generated seperatley. Doctor can also suggest a patient to DMP programme & cousellor/doctor can
enroll into the programme( interaction with doctor & wards module to receive the request (added to prospective list ) & enrolled members of the programme.
Doctor/cousellor should be able fill the form & asses, plan for the treatment the patient .
Once doctor enroll & assess patient into programme- predictive analysis report is imported from DMP software (integrated from DMP software )
All investigation & cosultation summary under the programme to be captured against the Programme ID & UHID , Also the vital/ critical parameters collected through contact centre also to be integrated . In short all patient related clinical information to be made available to the doctor in single view/ snap shot.
DMP should get a report of chronic diseased patients from the EMR on daily/weekly/bi-weekly basis (customizable).
End of the programme the report goes to the patient through e-mail.
Patient enrolled into programme only after bill payment.
It should provide the feature to add DMP programs.
Auto generated Email should be sent to the DMP patients for scheduled visits.
Alternate / Flexibility Options in the Business Process
-NA-
Outputs Reports are generated on
o List of patients joined in DMP program (breath easy/CVD program)
o List of patients who are suffering from chronic disease (Cardio, cancer, diabetes, Asthma).
Messages -NA-Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 105 of 232
MedMantra Software Requirements Specifications ver.0.1
Process Checklists
S. No
Check list
Code
Check list
Name
Description
Triggering Event
Check Items
Business Rules for Generation
-NA-
Alerts / Reminders / Notifications
Sr. NoRequest Code Request Name Time LimitAction Required
Alert MessageNotify UserNotify mechanism
Remarks
-NA-
For Internal Use Page 106 of 232
MedMantra Software Requirements Specifications ver.0.1
3.5 Programme Management
Draft UI for Seeting up a Programme by programme owner
3.5.1 Program Management Set up
3.5.1.1 Business Process DetailsDescription It describes the entire set up required for a program i.e. planned & conducted in a Hospital,
also it aims at the target customers for the program, benefits of the program and the beneficiaries of the same.
Sometimes marketing department takes some special initiatives to give special attention to some segment of the society. Customer associated to the program is mapped to one of the staff from operation or marketing to escort them during their visit so that their visit is Hassel free/personalized services like previous investigation reports/ final bill/ treatment summaries etc which were not collected during their last visit or to be collected.
Also whenever a transaction is made out of the scheduled visit times at admission counter/billing counter/any other service areas the message will go to corresponding employee who is taking care of the patient. So that even if visit is unscheduled, information goes to the employee to take care of that patient.
For Internal Use Page 107 of 232
MedMantra Software Requirements Specifications ver.0.1
Among the programme beneficiaries there would be some VIP customers whose visit to the hospital should also be notified to the programme owner also apart from employee assigned to take care of that patient.
The system should have following capabilities:
Define a programme- name, description, target customer profile, services included as part of the programme/ agreement applicable for the programme members, materials to be issued to the programme members
ADD customers to the programme- system should be flexible enough to add customer to the programme at the time registration/admission also part from the manual addition of the programme.
Addition of VIP members in the programme- While manually adding members to the programme there can be flag to mark them as VIP customers or all those VIP – patient type (as in registration) can also be automatically added under the VIP customers.SMS/communication goes to the programme owner also if VIP customer visits the hospital
Work list for programme owner/employee- whenever there is visit scheduled the member details, visit details ,Previous episode details with the clinical summaries, bills associated with the episode , next visit date & time if already scheduled.
Configuration required to send automatic message when ever unscheduled visit of VIP customers& Automatic message to the employee before x hours/y days of visit date & time.
Users with access control
Program Beneficiary Owners i.e. authorized users who will be defined as owners in the set up
Pre – requisites
For Internal Use Page 108 of 232
MedMantra Software Requirements Specifications ver.0.1
Business Process Details
Program Definition - Define the name of the Program Provision to describe the programme. Provision to capture Program Applicability dates i.e. From Date & To Date,
Gender & Location Program shall be active only for the period defined Provision to describe the Target Customer Profile which shall be displayed
in the Registration screen .while generating registration number – provision to flag the patient to include the customer into the programme (so that information can be made available and eligible customers can be flagged as program beneficiaries)
Services to be included as a part of the program – can be linked to Agreement through which the tariff for the services shall be driven for the customers. The services may be provided on a cash or credit basis.
If agreement is not selected then Search criteria to select service name - filter based on Department, Service category , Service name & also provision to capture the discount against each of the service selected
Materials to be used for a customer of the program can be set, E.g. Card (Program specific Card to be issued to customer to identify the customer), etc. Items can also be selected from a profile created in MM (TBD).
Define Material Item Name and add option for multiple material/items to be issued or used for each customer.
Also need to have an option to add total available numbers against each item (Inventory status shall be updated based on the items issued or used for the customer).
Program Owner Set up –
Employee IDs to be selected and added as owners of the program who shall be taking care of the customers.
Against each Program owner the target number of customers, period for which the target is set for the owner, so option to ADD against all the owners about the set targets for the same.
Alternate / Flexibility Options in the Business Process
-NA-
Outputs Program ID to be created against program Name. Programme attached to UHID & linked UHID
Messages SMS alert to configured in SMS component, trigger points & message to be decided
Exception handling
-NA-
Error Reporting -NA-
Scheduling -NA-
Trigger In -NA-
For Internal Use Page 109 of 232
MedMantra Software Requirements Specifications ver.0.1
Trigger Out -NA-
Assumptions -NA-
3.5.1.2 Input/AttributesAttribute
NameDescriptio
nData Type
Length
List of
values
Conditions Logic
Validation
Compliance
Remarks
Name of the programme
Programme name
Varchar
75
Programme description
Description Varchar
200
Location Varchar
50 Location
As in registration LOV
From date Programme validity
date
To Date Programme validity
Date
Target no. of customers
No. Number
Target customer profile
Target profile
Varchar
200
Applicable to Age gender etc
varchar
Age numberGender Male or
female & all
Varchar
Material request
Varchar
Materials for programme customer
Programme ID
Generated on saving details
Linked to UHID
For Internal Use Page 110 of 232
MedMantra Software Requirements Specifications ver.0.1
3.5.2 ADD CUSTOMER TO THE PROGRAMME
3.5.2.1 Business ProcessDescription Customer associated to the program is mapped to one of the staff from operation or
marketing to escort them during their visit so that their visit is Hassel free/personalized services like previous investigation reports/ final bill/ treatment summaries etc which were not collected during their last visit or to be collected.
Depending on the No. of customers under the programme , customer to employee can be mapped. If the number of customers is more than customers can be mapped against different employee for easier co-ordination. i.e. if 50 members are available then the 20 can be attached to one employee 30 to another employee
The system should have following capabilities:
1. ADD customers to the programme- system should be flexible enough to add customer to the programme at the time registration/admission also part from the manual addition of the programme.
2. Addition of VIP members in the programme- While manually adding members to the programme there can be flag to mark them as VIP customers or all those VIP – patient type (as in registration) can also be automatically added under the VIP customers.SMS/communication goes to the programme owner also if VIP customer visits the hospital
For Internal Use Page 111 of 232
MedMantra Software Requirements Specifications ver.0.1
3. Linked UHID- The primary member family members can also be part of the programme. Once a family members UHID is linked to the main UHID then provision to flag whether to include the linked UHID also under programme to be available.
4. Provision to enter the secretary details & mailing address. /contact number to be available. If reports/bills etc are to be sent to the customer then can be sent to the mailing address provided here
Users with access control
Program Beneficiary Owners i.e. authorized users who will be defined as owners in the set up
Pre – requisites Program ID to be created against program Name
Business Process Details
ADD Customer Details – The existing patients can be added to the program, select UHID of the patients and
add to the program UHID Search icon to be provided to search patient, once the patient is added to the
program it shall display the Material/Item issue/use status in a grid below as shown in the UI draft layout.
Program owner to be attached to the each customer/patient UHID. Provision to capture the address, name of the secretary of the customer/patient,
Secretary Contact details against the UHID selected. The patient address against UHID shall be auto populated but can be appended with
the latest one. Provision to save/update & view to be available.. Provision to capture Family members UHID to be linked up with the
Customer/patient UHID. (Link functionality of Registration can be used to link family members of the customer/patient)
Program Calendar Setup – This should provide functionality to set up a program calendar. This calendar would define the activities to be carried over or services to be provided
to a member over a period of time.These activities would then get populated in the program owner’s work list at the appropriate time so that a reminder can be sent to the patient.Or While adding the customer/after a member is added to the programme there should be provision to schedule the visit of the patient. Once a visit is scheduled the details appear in the work list .Also there should be provision to register the patient.
Alternate / Flexibility Options in the Business Process
-NA-
OutputsMessages SMS alert to configured in SMS component, trigger points & message to be decided
Exception handling
-NA-
For Internal Use Page 112 of 232
MedMantra Software Requirements Specifications ver.0.1
Error Reporting -NA-
Scheduling -NA-
Trigger In -NA-
Trigger Out -NA-
Assumptions -NA-
3.5.2.2 Input AttributesAttribute
NameDescriptio
nData Type
Length
List of
values
Conditions Logic
Validation
Compliance
Remarks
Name of the programme
Programme name
Varchar
75 Auto populated from programme set up
Programme description
Description Varchar
200 Auto populated from programme set up
Location Varchar
50 Location
As in registration LOV
From date Programme validity
date Auto populated from programme set up
To Date Programme validity
Date Auto populated from programme set up
Target no. of customers
No. Number
Auto populated from programme set up
Target customer profile
Target profile
Varchar
200 Auto populated from programme set up
Applicable to Age gender etc
varchar
Auto populated from programme set up
Age number Auto populated from programme set up
Gender Male or female & all
Varchar
Auto populated from programme set up
Material request
Varchar
Materials for programm
Auto populated from programme set up
For Internal Use Page 113 of 232
MedMantra Software Requirements Specifications ver.0.1
e customer
Address Varchar
100
Secretary name
Varchar
50
Secretary number
number
E-Mail Varchar
50
Owner Varchar
50
3.5.3 Program Owner Work List
3.5.3.1 Business ProcessDescription It describes the functionalities of Program Owner Work list where complete information to manage
program beneficiaries i.e. taking care of the customers of the program post, pre hospital & during
For Internal Use Page 114 of 232
MedMantra Software Requirements Specifications ver.0.1
the hospital visit, The eligible customers are given special attention by the respective program owner and information about the customer & service criteria are guided by the system as per the program definition.
Work list is created based on
1. The visits scheduled by the programme employee/ owner
2. Also the unscheduled visit details- whenever any transaction happens at any of the service areas (Admissions, Appointment, billing etc)
Users with access control
Program Owners i.e. It shall show the respective customer list to that owner as per the set up /scheduled visit
Pre – requisites Program ID, Program owners & Customer flagged under this program
Business Process Details
Basic Functionalities of work list for owners Link of the “ADD CUSTOMER DETAILS” For the new customers who are eligible for the
program, upon clicking it shall open up the page where a customer details can be added (refer the program set up )
For the existing customers who are coming for a visito Information in the work list of respective Program owner i.e. Patient UHID,
Name/Age/Gender, Visit scheduled Time, Purpose of visit, Date of last visit, services availed during last visit, status of the services raised in this visit
Planned Visit – through scheduler the information is captured and reflects in the work list
Emergency/Walk-in Visit – It reflects in the work list triggered from the first transaction happens against the customer UHID, also a SMS goes automatically to the respective program owner./employee assigned.
o Visit scheduling for the customer prior to the customer visito Services availed by the patient/customer during the visit shall be displayed to the
respective owner in the Program Management task list.o Follow up details against each customer shall be displayed i.e. an icon to be
displayed against a patient and upon clicking that it shall show all the dates of follow up and details captured against each.
o Option to view investigation results and take print out of the reports of the services the customer has already availed and also the status of the each service rendered.
o Also shall have an option to view all the episodes (chronological order) against each customer, also the prescriptions and diagnosis to be displayed for each episode of care.
Inter Module Interaction – It shall show some icon against patient demographic details to identify the patient. Link of Program set up page to be provided at Registration page to add customer to this
program. The same link needs to be enabled at Admission page to add a customer to this program. Programme Id along which benefits of the programme to available in billing module
against the UHID
For Internal Use Page 115 of 232
MedMantra Software Requirements Specifications ver.0.1
Alternate / Flexibility Options in the Business Process
-NA-
Outputs Programme details are displayed against the UHID in billing
Messages SMS alert to configured in SMS component, trigger points & message to be decided
Exception handling
Error Reporting -NA-
Scheduling -NA-
Trigger In -NA-
Trigger Out -NA-
Assumptions -NA-
3.5.3.2 Input/AttributesAttribute
NameDescriptio
nData Type
Length
List of
values
Conditions Logic
Validation
Compliance
Remarks
Name of the programme
Programme name
Varchar
75 Auto populated from programme set up
Programme description
Description Varchar
200 Auto populated from programme set up
Location Varchar
50 Location
As in registration LOV
From date Programme validity
date Auto populated from programme set up
To Date Programme validity
Date Auto populated from programme set up
Target no. of customers
No. Number
Auto populated from programme set up
Target customer profile
Target profile
Varchar
200 Auto populated from programme set up
Applicable to Age gender etc
varchar
Auto populated from programme set up
Age number Auto populated from programme set
For Internal Use Page 116 of 232
MedMantra Software Requirements Specifications ver.0.1
upGender Male or
female & all
Varchar
Auto populated from programme set up
Material request
Varchar
Materials for programme customer
Auto populated from programme set up
Address Varchar
100 Auto populated from programme set up
Secretary name
Varchar
50 Auto populated from programme set up
Secretary number
number
Auto populated from programme set up
E-Mail Varchar
50 Auto populated from programme set up
Owner Varchar
50 Auto populated from programme set up
Programme ID
Programme ID linked to the UHID
Visit scheduled
Date &time
As in appointment booking if Op appointment
Next visit scheduled
Date & time
As in appointment booking if Op appointment
Last visit details
Auto populated based on UHID
Materials to be issued
Varchar
50 Linked to the Programme ID
Auto populated only during first visit scheduled
Contact no. Number
As in registration
Patient name Varchar
50 A sin registration
For Internal Use Page 117 of 232
MedMantra Software Requirements Specifications ver.0.1
3.6 Customer Loyalty Programme Through this process business tracks the customers visit and spending pattern and give some score for his spending depending on the score business provides some benefits in the form of discount or free services as per the defined business policy.
System should help the business to:
Define Loyalty programme
Register customers in different loyalty program
Provide Loyalty Card to its customers (Bar-coded or any other technical device)
Define business rule for earning points
Define business rule for burning points and cancel service after availing point advantage.
Map points to loyalty program process
Have audit trail for each point earned and burnt
Business Process DetailsDescription The loyalty program allows a patient to “earn” points based on his/her loyalty and usage of the
hospital services and to “burn” or spend these points to avail services or products at the hospital or other allied service providers.
Sometimes marketing/ operations department takes some special initiatives to Reward the loyal customers based on different loyalty drivers such as Revenue generated, services utilized, No. of visits made to the hospital , purchases made at partner group. Based on the reports generated on the above criteria/ loyalty drivers the Customers enrolled under the programme.
A loyalty card can be offered through which members earns & burns his points/reward by swiping at POS across group & also at partner group. Issued card number & details can linked to an UHID. or can be redeemed by customer & also by his family /friends etc.Through the website the member can also view the points he has earned & through the reward catalogue he can redeem the voucher which can redeemed at any of the group hospitals or partner groups.
The system should manage:
o Defining/Creation of loyalty programme.- Create a loyalty programme through which the member earns or burns points/reward
o Register customers in different loyalty program- eligible customers can be added under the programme. Bulk upload option can also be provided if the no. of customers are more
o Provide Loyalty Card to its customers (Bar-coded or any other technical device)
o Define business rule for earning points- Configuration for setting up Rules for point accumulation & redemption based on various loyalty drivers.
o Define business rule for earning points- Configuration for setting up Rules for point accumulation & redemption based on various loyalty drivers.
o Application of rule for awarding points under the programme- Attach the rule for earning/burning points/reward to programme which has been created.
For Internal Use Page 118 of 232
MedMantra Software Requirements Specifications ver.0.1
o Application of rule for burning points under the programme
o Automatic Point accumulation & deduction after every transaction .o Earning/Burning of points should be possible across group hospitals & also at partner
group. Also provision to define under the programme definition whether Redemption can be against the member UHID or family member UHID( linked UHID’s)
o Loyalty card – which can swiped at POS device to redeem the points/reward. Also the card can act as debit card if any bulk deposit is made against the UHID of the patient. i.e. The amount can be debited from the card & credited against the selected service which is being utilized. UHID card can also act as Loyalty card/ separate card can be issued to the member
o A single patient can be eligible for different loyalty programmes – Configuration required for applying the relevant redemption rule in such cases (TBD).Single/multiple loyalty programmes ID’s can be linked to UHID
o Loyalty website- A site that enables members to perform self service such as updating their personal profile, viewing their transaction history and submitting service requests.
o Transactions- The basic data structure and functionality used to store and display members purchases (for e.g.- each time he buys a service, accrual transaction is created) Automatic transaction creation and processing. All accrued/debited points are the result of a transaction
o Programme ID to be linked with the UHID hence with the billing .The details of programme, points earned & can be redeemed under the programme should have link with the billing module. If redeemed by the patient, based on the points redeemed amount can be adjusted against the bill.
o Provision in t he billing where the programme details are viewed & necessary details are captured (such as programme ID, Points earned, Reward/points they want to redeem , corresponding amount to be adjusted in the bill ( reference Programme ID, Transaction record against Points earned
Users with access controlPre – requisites Business Process Details
1. The patient’s usage of hospital services is tracked through his/her UHID number2. Points are allotted to the patient based on various parameters which may include:
o Revenue generated – Depending on whether Revenue generated at hospital or partner can have different points accrued to their accounts
o Number of visits- based on the type of service for which the customer visited the hospital the earning/burning the reward/points will happen
o Number of referred patients and their visits/revenue- every time a /referral doctor/referral organization refers a patient to the hospital points can be accrued & redeemed
o Service /service type- Based on the service which has been utilized there could be points/reward attached during the present visit/future visit.
o Other factors which may be decided from time to time.o All the rewards are translated into points which can be redeemed into amount or
For Internal Use Page 119 of 232
MedMantra Software Requirements Specifications ver.0.1
service /discounts etc Define Loyalty campaign name along with description & owner of the programme
a) Owner of the programme
b) Provision to select the Applicable criteria for programme (demographics/service type/diagnosis/treatment etc)
c) Programme ID created after saving the defined loyalty programme
Define rules for Point calculation(earning /Burning points) Application of Logic for awarding points under the programme
a) For the defined Programme the applicable logic for point /reward calculation b) Also the logic to be used while redeeming the reward/points under the
programme will be defined. Audit trail for each earning/burning of point3. Services availed at pharmacies, other group hospitals, clinics, etc. should be tracked. For
this we should be able to consolidate the UHID numbers from various group hospitals.4. Patient should be able to check his/her activity and the points accrued in his/her account
at any hospital counter or by logging in to a website.5. Once a patient selects the service they want to redeem, the voucher or product should be
dispatched to the patient and appropriate points should be deducted from the patient’s account.
6. Regular (monthly/quarterly or annual) statement of accounts and activities for each patient should be generated and dispatched by mail or email.
7. Redemption of points to pay for services at the hospital should be possible in real time.
8. Member profile- A record of relevant member information such as occupation, address, family, communication preference, transaction history, tier history if any, communication history to be maintained.
9. Tiers/segments- grouping of members who share common characteristics (segments) or who share same status with the company (tiers).If any tier /segmentation system is followed by the business. Configuration required to define the tier & eligibility criteria for member to come under the tier/segment.
10. Accruals/earnings – the points a member earns for purchasing different services (from both hospital & partner group)
11. Targeted earning/accruals rules that encourage members to purchase selected product/services or perform designated actions during a defined period
12. Redemption/burning of points/rewards – the points the member use to purchase a service either from hospital/partner group
13. System /Application performs a variety of actions, including awarding or deducting member’s points, moving members between tiers, expiring points and creating statements. Partner companies can enroll in the program and members can earn by purchasing partners product/service (for e.g.- pharmacy/wellness) or use points to purchase product/service from any other partner.
14. Redemption can be against the member UHID or family member UHID( linked UHID’s)
For Internal Use Page 120 of 232
MedMantra Software Requirements Specifications ver.0.1
Alternate / Flexibility Options in the Business Process
-NA-
Outputs 1. Regular (monthly/quarterly or annual) statement of accounts and activities for each patient should be generated and dispatched by mail or email.
2. Reports/analytics – programme wise reports on promotions ROI/partners value to the host/hospital.
- Programme analysis-Membership Analysis Details in the report section-Partner analysis
Programme wise reports on promotions ROI/partners value to the host/hospital.
-Programme wise material consumption value report
Programme wise member profile
-Periodic reports on point statement to customer.
Messages SMS every time point credited or debited.
Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-
Trigger In -NA-
Trigger Out -NA-
Assumptions -NA-
3.6.1 Define the Programme
Description Programme is designed after the careful thought process of operations/marketing team. The programme will be defined in terms of its target profile including the eligible criteria of the members under the programme along with validity & host company which is offering the programme & locations covered under the programme.
Programme ID is generated after the programme is created which will be linked to UHID ‘s of members under the programme.
System should manage:
Define the programme in terms of its name, description, applicable dates, eligible criteria, materials to be issued under the programme etc.
Application Rule for awarding points under the programme- Attach the rule for earning/burning points/reward to programme which has been created.
Application Rule for burning points under the programme
Configuration as to whether the card holder can also avail the points available against any family member/friends bill if he desires to be defined in the
For Internal Use Page 121 of 232
MedMantra Software Requirements Specifications ver.0.1
programme. Provision to capture the series no. with which the card numbers under the
programme will start. Card series No. for a programme to be unique. All card issues under the programme will start with that programme.I.e. programme no. P1 the series starts with 10 etc.
Programme ID to be linked with the UHID hence with the billing .The details of programme, points earned & can be redeemed under the programme should have link with the billing module. If redeemed by the patient, based on the points redeemed amount can be adjusted against the bill.
Tie partner associated with programme also to be captured. Points earned at partner entity also exhanged for services/discounts from
the parent group.
Users with access controlPre – requisites Business Process Details
Program Definition - Define the name of the Program Provision to describe the programme. Provision to capture Program Applicability dates i.e. From Date & To Date,
Gender & Location at which the programme will be applicable. Program shall be active only for the period defined Provision to describe the Target Customer Profile which shall be displayed in the
Registration/admission screen. provision to flag the patient into the programme with the registration no.((so that information can be made available and eligible customers can be flagged as program beneficiaries)
Provision to select the Eligible criteria of the members to be eligible under the programme (demographics/service type/diagnosis/treatment etc). The eligible criteria defined under the programme should match with the member profile.
o Eligible criteria based on the Demographic details such as age & gender etc
o Eligible criteria based on the Service /services being utilizedo Eligible criteria based on the No. of visits made to hospital for a
particular service.o Eligible criteria based on the particular diagnosis /treatment profile of
patients. Materials to be used for a customer of the program can be set, E.g. Card
(Program specific Card to be issued to customer to identify the customer), etc. Items can also be selected from a profile created in MM (TBD).
Define Material Item Name and add option for multiple material/items to be issued or used for each customer.
Also need to have an option to add total available numbers against each item (Inventory status shall be updated based on the items issued or used for the customer).
Provision to flag whether programme benefits can also be used by family members also.
For Internal Use Page 122 of 232
MedMantra Software Requirements Specifications ver.0.1
Card series No. for a programme to be unique. All card issues under the programme will start with that programme.I.e. programme no. P1 the series starts with 10 etc.
o Programme ID to be linked with the UHID hence with the billing .The details of programme, points earned & can be redeemed under the programme should have link with the billing module. If redeemed by the patient, based on the points redeemed amount can be adjusted against the bill.
o Provision in t he billing where the programme details are viewed & necessary details are captured (such as programme ID, Points earned, Reward/points they want to redeem , corresponding amount to be adjusted in the bill ( reference Programme ID, Transaction record against Points earned
Program Owner Set up – Employee IDs to be selected and added as owners of the program who shall be taking care of the customers. Against each Program owner the target number of customers, period for which
the target is set for the owner, so option to ADD against all the owners about the set targets for the same.
Alternate / Flexibility Options in the Business Process
-NA-
Outputs Loyalty programme ID generated
Messages SMS every time point credited or debited.
Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-
Trigger In -NA-
Trigger Out -NA-
Assumptions -NA-
3.6.2 REGISTER CUSTOMERS IN LOYALTY PROGRAMME
Description Customer eligible for the programme designed the members can be added to the programme
Based on the reports available in the report section the desired customer profile selected & can be either export uploaded in bulk or can manually one by one.
The system should have following capabilities:
Based on whether programme benefits can also be extended/used by family members also.
5. Register a particular patient under a specific programme.
6. Bulk upload of all the UHID no. against a programme
For Internal Use Page 123 of 232
MedMantra Software Requirements Specifications ver.0.1
7. Should be able to generate card once the member is enrolled/registered
8. Load points once registered based on the rules applicable to the programme.
9. Linked UHID- The primary member family members can also be part of the programme. Once a family members UHID is linked to the main UHID then provision to flag whether to include the linked UHID also under programme to be available.
10. In the billing a there should a provision to view the programme details against that card/UHID(Programme name, UHID,Last transaction details, total points earned. Business rules applicable for that programme/card holder)
Users with access control
Program Beneficiary Owners i.e. authorized users who will be defined as owners in the set up
Pre – requisites Program ID to be created against program Name
Business Process Details
ADD Customer Details – The existing patients can be added to the program, select UHID of the patients and
add to the program. UHID Search icon to be provided to search patient, once the patient is added to the
program it shall display the programme list from the admistrator will select the appropriate programme.
The bulk list of existing patients can be added to the program, select UHID of the patients and add to the program
Once the programme selected option to generate the card with the following details printed on it.
o card holder nameo card numbero UHIDo Programme name etc
The patient address against UHID shall be auto populated but can be appended with the latest one.
Provision to capture Family members UHID to be linked up with the Customer/patient UHID. (Link functionality of Registration can be used to link family members of the customer/patient)
Should be able to generate card once the member is enrolled/registered Card series No. for a programme to be unique. All card issues under the
programme will start with that programme.I.e. programme no. P1 the series starts with 10 etc.
Alternate / Flexibility Options in the Business Process
-NA-
OutputsMessages SMS alert to configured in SMS component, trigger points & message to be decided
Exception -NA-
For Internal Use Page 124 of 232
MedMantra Software Requirements Specifications ver.0.1
handling
Error Reporting -NA-
Scheduling -NA-
Trigger In -NA-
Trigger Out -NA-
Assumptions -NA-
3.6.3 Define Earning Point:
Description This process helps the user to define the business rule for earning points which will interns will be mapped to loyalty program.
Users with access control
Loyalty program administrator
Pre – requisites Business Process Details
System allows the user to define a business rule with following attributes:
Name of the Earning Rule
Logic based on any of the three criteria Revenue or Visit related or Referral of patient
If revenue then map Rs. XXXX to Point YYY
o Multiple rule based revenue created i.e. how many points one would get is based on revenue could be different for different programmes. For e.g.- Rs 1000 can translate into 10 points under one programme. Under different progarmme Rs 1000 can be translated into 1 point only.
o So, multiple rules can be created with different rule number.
o Based on the need these rules can be created by Loyalty administrator.
If Visit then For 1 OP visits XXX points, for AHC visit XXXX points for IP admission XXXX points.
System should allow creating multiple earning point business rules which will in turn will be mapped to each loyalty program (Ref. Map points to loyalty program process.
Each rule defined will have a unique name , logic on which the rule is based & rule number.
When rules of the same category are selected, the system should allow only one rule from that particular category to be applicable
o i.e If two rules selected from revenue category then system should not allow to select both under the programme , should allow only one rule to be selected from that particular category.
Rules from different categories can be applied to single programme.
Alternate / Flexibility Options in the Business ProcessOutputs Business rule for earning points defined. Business rule number generated.
For Internal Use Page 125 of 232
MedMantra Software Requirements Specifications ver.0.1
MessagesException handlingError ReportingSchedulingTrigger InTrigger Out Map earning point rule to loyalty program
Assumptions
DescriptionUsers with access control
Loyalty program manager
Pre – requisites Business Process Details
Alternate / Flexibility Options in the Business ProcessOutputsMessagesException handlingError ReportingSchedulingTrigger InTrigger OutAssumptions
3.6.4 Define business rule for burning points
Description This process helps the user to define the business rule for Burning points which will intern will be mapped to loyalty program.
Users with access control
Loyalty program administrator
Pre – requisites
For Internal Use Page 126 of 232
MedMantra Software Requirements Specifications ver.0.1
Business Process Details
System allows the user to define a business rule with following attributes:
Name of the Burning Rule
Burning of points can be in two forms either in amount or free service
Points can be burned for rupees or free service i.e Points zzzz map Rs. XXXX or service YYY
System should allow creating multiple burning point business rules which will in turn will be mapped to each loyalty program (Ref. Map points to loyalty program process.)
Each rule defined will have a unique name , logic on which the rule is based & rule number.
Rules from different categories can be applied to single programme.
Redemption rule/burning rule applicable to the programme to be displayed in billing to view details while redeeming the points.
Alternate / Flexibility Options in the Business ProcessOutputs Business rule for earning points defined. Business rule number generated.
MessagesException handlingError ReportingSchedulingTrigger InTrigger Out Map earning point rule to loyalty program
Assumptions
DescriptionUsers with access control
Loyalty program manager
Pre – requisites Business Process DetailsAlternate / Flexibility Options in the Business ProcessOutputsMessagesException
For Internal Use Page 127 of 232
MedMantra Software Requirements Specifications ver.0.1
handlingError ReportingSchedulingTrigger InTrigger OutAssumptions
3.6.5 Map Rules to loyalty program processDescription It describes the Logic based on which the points/benefits are accrued by the member & burning
redeeming rule applicable under the programme.
System should manage.
Earning /burning points based on Applicable Point Earning/Burning rules for the programme
Information of programme, Card details & burning rules to be populated in billing.
While redemption the billing executive sees all the relevant details & by filling up necessary card details he will enter burned points .
Once points burned then the bill is affected accordingly.
Cancellation of services
o If the points redeemed against a single service then
o Amount refunded is the amount derived after discount ( should not include the amount discounted against the points.) i.e as per Existing billing cancellation policy if discounts are availed
o Points are remitted to the card again
o If the points redeemed against bill with multiple services
If the amount redeemed against the points is less than the bill for Non- cancelled services then
o Refund amount will be same as bill amount of the cancelled services.
o If the amount redeemed against points is more than amount of non- cancelled services.
o Then amount discounted (against the points) for non cancelled services will remain same
o For rest of amount discounted against the cancelled service- Amount refunded is the amount derived after discount ( should not include the amount discounted against the points.) i.e as per Existing billing cancellation policy if discounts are availed.
Points are remitted to the card again
Users with access control
Program Owners i.e. It shall show the respective customer list to that owner as per the set up /scheduled visit
Pre – requisites Program ID, Program owners & Customer flagged under this program
Business Process Details
1. The patient’s usage of hospital services is tracked through his/her UHID number2. Points are allotted to the patient based on various parameters which may include:
o Revenue generated – Depending on whether Revenue generated at hospital or
For Internal Use Page 128 of 232
MedMantra Software Requirements Specifications ver.0.1
partner can have different points accrued to their accountso Number of visits- based on the type of service for which the customer visited the
hospital the earning/burning the reward/points will happeno Number of referred patients and their visits/revenue- every time a /referral
doctor/referral organization refers a patient to the hospital points can be accrued & redeemed
o Service /service type- Based on the service which has been utilized there could be points/reward attached during the present visit/future visit.
o Other factors which may be decided from time to time.o All the rewards are translated into points which can be redeemed into amount or
service /discounts etc Once programme is defined the Rules for earning/burning points under the programmes
are definedo Multiple rules for earning or burning can be mapped against a programme
Once points burned then the bill is affected accordingly.
Cancellation of services
o If the points redeemed against a single service then
o Amount refunded is the amount derived after discount ( should not include the amount discounted against the points.) i.e as per Existing billing cancellation policy if discounts are availed
o Points are remitted to the card again
o If the points redeemed against bill with multiple services
If the amount redeemed against the points is less than the bill for Non- cancelled services then
o Refund amount will be same as bill amount of the cancelled services.
o If the amount redeemed against points is more than amount of non- cancelled services.
o Then amount discounted (against the points) for non cancelled services will remain same
o For rest of amount discounted against the cancelled service- Amount refunded is the amount derived after discount ( should not include the amount discounted against the points.) i.e as per Existing billing cancellation policy if discounts are availed.
Points are remitted to the card again
Alternate / Flexibility Options in the Business Process
-NA-
Outputs Programme details are displayed against the UHID in billing
Messages SMS alert to configured in SMS component, trigger points & message to be decided
Exception handling
Error Reporting -NA-
For Internal Use Page 129 of 232
MedMantra Software Requirements Specifications ver.0.1
Scheduling -NA-
Trigger In -NA-
Trigger Out -NA-
Assumptions -NA-
3.6.6 Have audit trail for each point earned and burntDescription Audit trail for each point earned and burnt to be maintained by system.
System should manage.
o The basic data structure and functionality used to store and display members purchases (for e.g.- each time he buys a service, accrual transaction is created) Automatic transaction creation and processing. All accrued/debited points are the result of a transaction
o Automatic Point accumulation & deduction after every transaction.
Users with access control
Program Owners i.e. It shall show the respective customer list to that owner as per the set up /scheduled visit
Pre – requisites Program ID, Program owners & Customer flagged under this program, HID
Business Process Details o Loyalty card – Each Point earned /burned under the programme against each card
holder has to be maintained.
o Also after card swiped at POS device to redeem the points/reward. Automatic Point accumulation & deduction after every transaction.
o Also the card can act as debit card if any bulk deposit is made against the UHID of the patient. i.e. The amount can be debited from the card & credited against the selected service which is being utilized. UHID card can also act as Loyalty card/ separate card can be issued to the member
Points earned at partner group as per the agrrement/MOU can be used across the parent/partner group. Trail for points earne dthrough partner group.
Alternate / Flexibility Options in the Business Process
-NA-
Outputs Programme details are displayed against the UHID in billing
Messages
Exception handling
Error Reporting -NA-
Scheduling -NA-
Trigger In -NA-
Trigger Out -NA-
Assumptions -NA-
For Internal Use Page 130 of 232
MedMantra Software Requirements Specifications ver.0.1
3.7 Patient preference card
Draft UI for Patient Preference card
3.7.1 Business processDescription Knowing each patient and his or her family members’ expectations, beliefs,
preferences, and choices will enable providers to deliver—through employees and enabling technologies—customized, personalized interactions and services. In short, the kind of experience that exceeds expectations.
Know Me”—Using Data to Understand Each Patient as a Unique Person .Patient preference card is maintained to know the patient.To truly know patients, hospitals should build from those sources and proactively capture additional information about patients’ desires and expectations; possibly with a pre/Post admission patient preference card The goal is to create a detailed and accurate patient preference profile. When providers truly know their patients’ individual preferences, they can personalize care with a combination of people- and technology-based approaches. For example, when it comes to hospital registration, some patients are delighted to preregister online or use a self-service kiosk in the lobby, while other patients expect to meet with a hospital employee.
Having this information can help a hospital be more flexible by providing different services to different patients. The information must be readily and securely available to caregivers and other staff .An Icon on the Nurse /secretary & doctor dashboard )both OP & IP cases will convey the recorded preferences
For Internal Use Page 131 of 232
MedMantra Software Requirements Specifications ver.0.1
or can act on the patient preference .
System should manage. Gather preference from various modules & display it through an icon
View & capture if any other preference exists
Display Information (on Trigger) at appropriate places & at appropriate time
NOTE -Configuration required to maintain an prefrence card ( if the business proposes to introduce preference form in future)
Users with access control
PRM user &all users in patient care areas
Pre – requisites Respective modules where prefernce is being captured
Business Process Details 1. Gather preference from various modules & display it through an icon
a) Patient preference captured in various modules are gathered at a single screen.
b) Food preference is captured by dietician
c) Room/Accommodation preference in AT
d) Language preference is captured in AT/Registration- can be included in patient panel (active patient with that UHID)
e) Apart from above preferences are captured in other modules (in future) will also be part of this profile
f) Also if any other preferences are mentioned by the patient in particular (apart from the above) provision to capture them should be available.
g) Previous feedback also gives some idea as to what the patient is expecting /service areas in which he is not happy about.
h) Likewise previous history (service utilized), their cultural beliefs, values/behaviors etc add value in complete understanding of the patient profile.
i) Old dues if any is pending also can be known to the nurse/patient care
2. View & capture if any other preference exists
a) Also if any other preferences are mentioned (apart from the above) provision to capture them should be available
b) Apart from above preferences are captured in other modules (in future) will also be part of this profile
For Internal Use Page 132 of 232
MedMantra Software Requirements Specifications ver.0.1
3. Display Information (on trigger points) at appropriate places & at appropriate time.(TBD)
a) Trigger Points- The challenge is to identify various trigger points at right places to right person. i.e. The information which is gathered should be conveyed to the concerned personnel at right time. E.g. - bed preference information gathered should be popped up whenever there is admission of the patient in the hospital.
b) Having this information can help a hospital be more flexible by providing different services to different patients. The information must be readily and securely available to caregivers and other staff in patient care areas.
c) An Icon on the Nurse /secretary & doctor dashboard )both OP & IP cases will convey the recorded preferences or can act on the patient preference
Inter module interactions
o All relevant modules such as registration,AT,Dietary/Appointment dashboard
Alternate / Flexibility Options in the Business Process
-NA-
Outputs Icon in All relavent modules, Doctor & wards, Admission, Op dashboard etc
o Periodic reports on Types of preferences across different set of attributes such as patient type, service type etc.
o Qualitative analysis on the other preference periodically
Messages
Exception handling
Error Reporting -NA-
Scheduling -NA-
Trigger In -NA-
Trigger Out -NA-
Assumptions -NA-
For Internal Use Page 133 of 232
MedMantra Software Requirements Specifications ver.0.1
3.8 Patient Activity check list
Draft UI for Patient Activity Check List
For Internal Use Page 134 of 232
MedMantra Software Requirements Specifications ver.0.1
3.8.1 Business ProcessDescription Operationalizes customized service delivery. Providing service to—and
communicating with—patients in ways they prefer will lead to enhanced brand loyalty, greater market share, and increased revenue.
System should manage. Configuration required to poulate the activity check list for an individual
patiento Extensive Mater set up required to generate activity list as per
the individual patient profile with regard to age/gender/disease/treatment/procedure. Etc also depending upon on the patient stauts, patient type, service type etc
o Should be ale to generate the activity list based on the set criteria . i.e when ever the patient record macthes with the set configuration the List is populated as per the set up.
o Manage con on the Ip dashboard/ doctor & ward dashboard(NURSE/DOCTOR/PR EXECUTIVE/PRM user)
Users with access control
PRM user &all users in patient care areas
Pre – requisites Inpatient Modules.
Business Process Details 1. Populate Patient activity check list when ever patient visits as
an Inpatient to the hospital
a. Patient activity list generated as per the configuration
b. On check out the activity check list disappears
c. On check in the activity check list appears
d. Whenever a new activity list item is added to list based on the configuration alert /icon highlighted.
2. Check the activities which were taken up
a. The activities which have been taken during the stay of the patient are checked.
b. Promotional activities which are suggested from the system can be explained to the patient by nurse/ Floor executive/Marketing team etc.
c. Upon clicking the promotional activity check box option to capture if the patient is interested in enrolling into the programme. this should go as work list to the DMP user.
d. Also all the patients for whom the system suggest for an DMP programme then that should also go as DMP programme work list for the DMP user.
Module interaction – DMP programme
For Internal Use Page 135 of 232
MedMantra Software Requirements Specifications ver.0.1
Alternate / Flexibility Options in the Business Process
-NA-
Outputs Icon in All relavent modules, Doctor & wards, Admission, Op dashboard etc
o Periodic reports on Types of preferences across different set of attributes such as patient type, service type etc.
o Qualitative analysis on the other preference periodically
Messages
Exception handling
Error Reporting -NA-
Scheduling -NA-
Trigger In -NA-
Trigger Out -NA-
Assumptions -NA-
3.9
3.10
3.11E-referrals
3.11.1 General Business Process DetailsDescription Effectively used, electronic referral management, e-Referral, provides an
alternative to the cumbersome, bureaucratic, paper-based referral process that has plagued physician practices, hospitals and health systems for decades. Only through e-referral can healthcare organizations improve information exchange, enhance patient care continuity. System should be able manage:
Web site Registration of refferal doctor- Login ID & passwaord to be created for each refferal doctor registered (CRM)
Refferal communicationo Configuration required to send automatic messages at
various status . Appointment booked On refferal
For Internal Use Page 136 of 232
MedMantra Software Requirements Specifications ver.0.1
On arrival to the hospital as IP/OP/Emergency OP/IP check in Diagnosis made/updated OP/IP checked out Arrived at emergency Others – option to capture the any other status At each of the above status configurable option
required to the automatic message through E-mail/SMS or both should be configurable
Configuration also to closed at what status the message goe sto whom( refferal doctor/primary doctor/callcentre/refferal doctor etc)
Request for refferal patient/cases
o Refferal doctor can send request through PC,IPAD or e-mail or SMS
o Refferal doctor can refer patient to a known doctor or speciality
o In both cases refferal ID generated. Refferal doctor ID feteched through CRM
o All SMS Received to the toll free Number will be received trough this screen. All SMS received to the toll free no. of the hospital ( Location wise toll free no. can be different, If different then the based on the Login it is controlled. If country wide toll free no. is common then All messages are received in the dashboard
o All E-mails received on the referral email -ID of the hospital ( Location wise email ID can be different, If different then the based on the Login it is controlled. If country wide email ID is same then All messages are received in the dashboard)
New patient with known /Unknown disease – provisional diagnosis details if available to be taken while taking request. PRN to be generatedagainst which request can be taken
Existing patients with known /Unknown disease- provisional diagnosis details if available to be taken while taking request.Request taken against UHID.
If the refferal patient is to arrive as emergency patient option to select/ capture the details of whom the request is transffered to ( e.g informed to emegency department, informed to ambulance etc) should be available.
Follow up of refferal patients
o Callcentre can manage the activity log of the refferal patients
o View all new refferal request received through SMS, E-mail, already received
o View all existing refferal requests received.
Configuration required to set up what portion of report will go to refferal doctor after the patient gets discharge dfrom hospital
o In case of LAB – entire report or only impression
For Internal Use Page 137 of 232
MedMantra Software Requirements Specifications ver.0.1
o In case of radiology- entire report or only impression o In case of OP patient- entire Op summary or diagnosis ,
treatment o In case of IP patient –select portion which has to go to the
refferal doctor ( what portion of discharge summary) Diagnosis Provisional diagnosis Course in hospital Treatment details Post discharge advice
Users with access controlPre – requisites
Request from referral doctor through web,IPAD, email, SMS to toll free number
Business Process Details
Referral Request created
a) By referral doctor
b) By Call centre
When patient gets referred (SMS/email/Website request), the call centre will get an intimation email/SMS.
Call Centre/referral desk will log-in in PRM- e referral & sees the referral patient details.
Call Centre will call the patient and book an appointment with the specialist
call centre will have
Activity log-- Activity log will have- Date & time of referral/referral Id, patient details & appointment details- when the appointment booked & who booked( role- call centre/referral doctor)
Date & time of referral/referral Id, patient details & appointment details- when the appointment booked & who booked( role- call centre/referral doctor
System will trigger intimation through ( appointment management –PRM) to various entities including a confirmation email to patient& referral doctor
Referral Doctor - Refers the Patient. Receives updates from Referral Desk. Referral doctor / will have
o Referral dashboard
a) Request raising, view & update referral s- Uses the request form & raises request for referral. Referral ID created
o Events/news from hospital
For Internal Use Page 138 of 232
MedMantra Software Requirements Specifications ver.0.1
o Education materials
Call centre/ Referral Desk –
o Books appointment for the referred patient, Informs referral desk and other entities
o Ensures priority treatment to referred patient, Gives updates to the referral doctor.
o Sends applicable summary message(emails/SMS) after OP/IP episode
Marketing Team - Over-views the process. Owner of the referral desk.
Apollo Consultant - Honor Appointments and enable priority treatment to referred patient
IP Services - Informs about the discharge of the preferred patient and provides discharge summary to the referral desk. Status updated from respective module.
Referral details in referral form auto populated in quick registration link against referral ID
Appointment booking is only for OP appointments
IP referrals are noted & if required bed reservation done if doctor advices for
Automatic Email/SMS to referral doctor after the check out of the patient - content in Op case & IP case is different
OP case – Op summary contents go to the referral doctor
IP case- A portion of discharge summary will be sent to referral doctor (internal consensus to be taken from doctors)
Referral notes & documents will appear in doctor dashboard against the particular patient details.
Email/SMS module integration
Inter module Interactiono ES- Appointment schedulero Appointment management – PRM Website/ portal where patient logs in & hospital representative(PRM
user) receives requests
Alternate / Flexibility
-NA-
For Internal Use Page 139 of 232
MedMantra Software Requirements Specifications ver.0.1
Options in the Business ProcessOutputs System will trigger intimation through ( appointment management –PRM)
to various entities including a confirmation email to patient& referral doctor
Messages SMS to concerned people as per the status as per the SMS configuration
Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.11.2 Registration of Refferal doctor
DescriptionRefferal doctor are enrolled in CRM by the marketing team. The referal sources are identified by the marketing team they approach the refferal doctor/organisation . After the intial introduction , an agreement is arrived at by both parties & refferal doctor is enrolled with apollo.
Once enrolled with apollo then the refferal ID craeted for the refferal doctor/organisation.Refferal doctor/organisation reffers patients to the apollo hospitals . Some of refferal doctor can also provided with IPAD or similar gadgets to refer patients ( depend on marketing department discretion)System should be able manage:
All refferal doctor/organisation have a unique ID created in CRMCRM Regsters the refferal doctor details such as
Refferal doctor/Organisation name Refferal doctor/organisation address/location
Refferal doctor /organisation contact details such aso Telephone no./mobile numbero E-mail ID
Login ID & passwaord to be created for each refferal doctor after the registration(CRM)
Refferal doctor can send request through the following
o Refferal doctor can send request through PC,IPAD or e-mail or SMS
o Refferal doctor can refer patient to a known doctor or speciality
o In both cases refferal ID generated. Refferal doctor ID
For Internal Use Page 140 of 232
MedMantra Software Requirements Specifications ver.0.1
feteched through CRM
Each refferal made by particular refferal doctor is linked to the refferal ID of the doctor & doctor payment is made based on the report in CRM .
Refferal doctor can also get points for reffering patients under the loyalty programme.
Users with access controlPre – requisites
Request from referral doctor through web,IPAD, email, SMS to toll free number.
Business Process Details Refferal doctor can send request through the following
o Refferal doctor can send request through PC,IPAD or e-mail or SMS
o Refferal doctor can refer patient to a known doctor or speciality
o In both cases refferal ID generated. Refferal doctor ID feteched through CRM
Each refferal made by particular refferal doctor is linked to the refferal ID of the doctor & doctor payment is made based on the report in CRM .
Refferal doctor can also get points for reffering patients under the loyalty programme.
Alternate / Flexibility Options in the Business Process
-NA-
Outputs System will trigger intimation through ( appointment management –PRM) to various entities including a confirmation email to patient& referral doctor
Messages SMS to concerned people as per the status as per the SMS configuration
Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 141 of 232
MedMantra Software Requirements Specifications ver.0.1
3.11.3 Receive Referral Request
Draft UI for Receive Refferal request
Draft UI for Refferal req uest recieval from Website
3.11.3.1 Business ProcessDescription System should be able manage:
Referal creation through web - the refferal doctor should be able login & fill the refferal form to send the request to refferal desk/Call
For Internal Use Page 142 of 232
MedMantra Software Requirements Specifications ver.0.1
centre. (Web site Registration of refferal doctor- Login ID & passwaord to be created for each refferal doctor registered )(CRM))
Request for refferal patient/cases
o Refferal doctor can send request through PC,IPAD or e-mail or SMS
o Refferal doctor can refer patient to a known doctor or speciality
o In both cases refferal ID generated. Refferal doctor ID feteched through CRM
Each refferal made by particular refferal doctor is linked to the refferal ID of the doctor & doctor payment is made based on the report in CRM .
Provision to generate PRN -New patient with known /Unknown disease – provisional diagnosis details if available to be taken while taking request. PRN to be generatedagainst which request can be taken
Provision to convert PRn to UHID also to available .
Existing patients with known /Unknown disease- provisional diagnosis details if available to be taken while taking request.Request taken against UHID.
All SMS Received to the toll free Number will be received trough this screen. All SMS received to the toll free no. of the hospital ( Location wise toll free no. can be different, If different then the based on the Login it is controlled. If country wide toll free no. is common then All messages are received in this dashboard
All E-mails received on the referral email -ID of the hospital ( Location wise email ID can be different, If different then the based on the Login it is controlled. If country wide email ID is same then All messages are received in this dashboard)
Users with access controlPre – requisites
Request from referral doctor through web,IPAD, email, SMS to toll free number
Business Process Details
Referral Request created
a) By referral doctor
b) By Call centre
When patient gets referred (SMS/email/Website request), the call centre will get an intimation through email/SMS.
Call Centre/referral desk will access - e referral & sees the referral patient details.
For Internal Use Page 143 of 232
MedMantra Software Requirements Specifications ver.0.1
Call Centre will call the patient and book an appointment with the specialist
call centre will have
Activity log-- Activity log will have- Date & time of referral/referral Id, patient details & appointment details- when the appointment booked & who booked( role- call centre/referral doctor)
Date & time of referral/referral Id, patient details & appointment details- when the appointment booked & who booked( role- call centre/referral doctor
If the patient is referred as an Inpatient the bed booking can be done & for day of admission.
If the patient referred as Outpatient then appointment is booked for concerned specialty/ doctor
If the patient is referred as emergency case then information regarding to whom the information is passed on to , date & time it is passed on to can be noted.
System will trigger intimation through ( appointment management –PRM) to various entities including a confirmation email to patient& referral doctor
Referral Doctor - Refers the Patient. Receives updates from Referral Desk. Referral doctor / will have
o Referral dashboard
b) Request raising, view & update referral s- Uses the request form & raises request for referral. Referral ID created
o Events/news from hospital
o Education materials
Call centre/ Referral Desk –
o Books appointment for the referred patient, Informs referral desk
Email/SMS module integration
Alternate / Flexibility Options in the Business Process
-NA-
Outputs System will trigger intimation through ( appointment management –PRM) to various entities including a confirmation email to patient& referral doctor
For Internal Use Page 144 of 232
MedMantra Software Requirements Specifications ver.0.1
Messages SMS to concerned people as per the status as per the SMS configuration
Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.11.4 Follow up of referral patients By Call centre
Activity Log in the website Updated by call centre after the follow up .
Description All the requests receieved through various sources will be received by Call centre/refferal desk.
Upon receiving the requests the PRM user Views all new refferal request received through SMS, E-mail, already received.
New refferal requests are follow upon to create refferal Id for refferal request & appropriate action to be taken.
Appointment booked Ip- bed reservation made for the patient & communication
goes to the consultant to whom the case is refferd / also refferal doctor& refferal desk
Emergency cases – the information communicated to emergency/ ambulance departement ( Name & date & time are also noted down)
For Internal Use Page 145 of 232
MedMantra Software Requirements Specifications ver.0.1
System should be able manage:
o Activity log of the refferal patients is updated automaticcaly when ever an action is taken on the request
o View all new refferal request received through SMS, E-mail, already received
o Refferal desk activities Updates the status of the patient Depending the status The message which needs
to sent is sent as per the configuration.(to all users involved)
After the visit the report issent to the patient, refferal doctor .
Configuration required to set up what portion of report will go to refferal doctor after the patient gets discharge dfrom hospital
o In case of LAB – entire report or only impressiono In case of radiology- entire report or only impression o In case of OP patient- entire Op summary or diagnosis ,
treatment o In case of IP patient –select portion which has to go to the
refferal doctor ( what portion of discharge summary) Diagnosis Provisional diagnosis Course in hospital Treatment details Post discharge advice
Users with access controlPre – requisites
Request from referral doctor through web,IPAD, email, SMS to toll free number
Business Process Details
call centre will have
Activity log-- Activity log will have- Date & time of referral/referral Id, patient details & appointment details- when the appointment booked & who booked( role- call centre/referral doctor)
System will trigger intimation through ( appointment management –PRM) to various entities including a confirmation email to patient& referral doctor
Referral Doctor - Refers the Patient. Receives updates from Referral Desk. Referral doctor / will have
o Referral dashboard
c) Request raising, view & update referral s- Uses the request form & raises request for referral. Referral ID created
o Events/news from hospital
o Education materials
For Internal Use Page 146 of 232
MedMantra Software Requirements Specifications ver.0.1
Call centre/ Referral Desk –
o Books appointment for the referred patient, Informs referral desk and other entities
o Ensures priority treatment to referred patient, Gives updates to the referral doctor.
o Sends applicable summary message(emails/SMS) after OP/IP episode
Appointment booking is only for OP appointments
IP referrals are noted & if required bed reservation done if doctor advices for
Automatic Email/SMS to referral doctor after the check out of the patient - content in Op case & IP case is different
OP case – Op summary contents go to the referral doctor
IP case- A portion of discharge summary will be sent to referral doctor (internal consensus to be taken from doctors)
Referral notes & documents will appear in doctor dashboard against the particular patient details.
Email/SMS module integration
Provision to send e-mail/SMS to both patient & referral doctor/organization.
Inter module Interactiono ES- Appointment schedulero Appointment management – PRM Website/ portal where patient logs in & hospital representative(PRM
user) receives requests
NOTE- If any Integration needs arise in the future then system should be able to cater to the needs
Alternate / Flexibility Options in the Business Process
-NA-
Outputs System will trigger intimation through ( appointment management –PRM) to various entities including a confirmation email to patient& referral doctor
Messages SMS to concerned people as per the status as per the SMS configuration
Exception handling
-NA-
For Internal Use Page 147 of 232
MedMantra Software Requirements Specifications ver.0.1
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.11.5 Manage Refferals
Description All the requests receieved through various sources will be received by Call centre/refferal desk.
Upon receiving the requests the PRM user Views all new refferal request received through SMS, E-mail, already received.
New refferal requests are follow upon to create refferal Id for refferal request & appropriate action to be taken.
Appointment booked Ip- bed reservation made for the patient & communication
goes to the consultant to whom the case is refferd / also refferal doctor& refferal desk
Emergency cases – the information communicated to emergency/ ambulance departement ( Name & date & time are also noted down)
System should be able manage:
For Internal Use Page 148 of 232
MedMantra Software Requirements Specifications ver.0.1
o Activity log of the refferal patients is updated automaticcaly when ever an action is taken on the request
o View all new refferal request received through SMS, E-mail, already received
o Refferal desk activities Updates the status of the patient Depending the status The message which needs
to sent is sent as per the configuration.(to all users involved)
After the visit the report issent to the patient, refferal doctor .
Configuration required to set up what portion of report will go to refferal doctor after the patient gets discharge dfrom hospital
o In case of LAB – entire report or only impressiono In case of radiology- entire report or only impression o In case of OP patient- entire Op summary or diagnosis ,
treatment o In case of IP patient –select portion which has to go to the
refferal doctor ( what portion of discharge summary) Diagnosis Provisional diagnosis Course in hospital Treatment details Post discharge advice
Users with access controlPre – requisites
Request from referral doctor through web,IPAD, email, SMS to toll free number
Business Process Details
call centre will have
Activity log-- Activity log will have- Date & time of referral/referral Id, patient details & appointment details- when the appointment booked & who booked( role- call centre/referral doctor)
System will trigger intimation through ( appointment management –PRM) to various entities including a confirmation email to patient& referral doctor
Referral Doctor - Refers the Patient. Receives updates from Referral Desk. Referral doctor / will have
o Referral dashboard
d) Request raising, view & update referral s- Uses the request form & raises request for referral. Referral ID created
o Events/news from hospital
o Education materials
Call centre/ Referral Desk –
For Internal Use Page 149 of 232
MedMantra Software Requirements Specifications ver.0.1
o Books appointment for the referred patient, Informs referral desk and other entities
o Ensures priority treatment to referred patient, Gives updates to the referral doctor.
o Sends applicable summary message(emails/SMS) after OP/IP episode
Appointment booking is only for OP appointments
IP referrals are noted & if required bed reservation done if doctor advices for
Automatic Email/SMS to referral doctor after the check out of the patient - content in Op case & IP case is different
OP case – Op summary contents go to the referral doctor
IP case- A portion of discharge summary will be sent to referral doctor (internal consensus to be taken from doctors)
Referral notes & documents will appear in doctor dashboard against the particular patient details.
Email/SMS module integration
Provision to send e-mail/SMS to both patient & referral doctor/organization.
Inter module Interactiono ES- Appointment schedulero Appointment management – PRM Website/ portal where patient logs in & hospital representative(PRM
user) receives requests
NOTE- If any Integration needs arise in the future then system should be able to cater to the needs
Alternate / Flexibility Options in the Business Process
-NA-
Outputs System will trigger intimation through ( appointment management –PRM) to various entities including a confirmation email to patient& referral doctor
Messages SMS to concerned people as per the status as per the SMS configuration
Exception handling
-NA-
Error Reporting
-NA-
For Internal Use Page 150 of 232
MedMantra Software Requirements Specifications ver.0.1
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.11.6 Refferal Desk
Description All the requests receieved through various sources will be received by Call centre/refferal desk.
Upon receiving the requests the PRM user Views all new refferal request received through SMS, E-mail, already received.
New refferal requests are follow upon to create refferal Id for refferal request & appropriate action to be taken.
Appointment booked Ip- bed reservation made for the patient & communication
goes to the consultant to whom the case is refferd / also refferal doctor& refferal desk
Emergency cases – the information communicated to emergency/ ambulance departement ( Name & date & time are also noted down)
System should be able manage:
For Internal Use Page 151 of 232
MedMantra Software Requirements Specifications ver.0.1
o Activity log of the refferal patients is updated automaticcaly when ever an action is taken on the request
o View all new refferal request received through SMS, E-mail, already received
o Refferal desk activities Updates the status of the patient Depending the status The message which needs
to sent is sent as per the configuration.(to all users involved)
After the visit the report issent to the patient, refferal doctor .
Configuration required to set up what portion of report will go to refferal doctor after the patient gets discharge dfrom hospital
o In case of LAB – entire report or only impressiono In case of radiology- entire report or only impression o In case of OP patient- entire Op summary or diagnosis ,
treatment o In case of IP patient –select portion which has to go to the
refferal doctor ( what portion of discharge summary) Diagnosis Provisional diagnosis Course in hospital Treatment details Post discharge advice
Users with access controlPre – requisites
Request from referral doctor through web,IPAD, email, SMS to toll free number
Business Process Details
System will trigger intimation through ( appointment management –PRM) to various entities including a confirmation email to patient& referral doctor
Referral Desk –
o Books appointment for the referred patient, Informs referral desk and other entities
o Ensures priority treatment to referred patient, Gives updates to the referral doctor.
o Sends applicable summary message(emails/SMS) after OP/IP episode
Appointment booking is only for OP appointments
IP referrals are noted & if required bed reservation done if doctor advices for
Automatic Email/SMS to referral doctor after the check out of the patient - content in Op case & IP case is different
For Internal Use Page 152 of 232
MedMantra Software Requirements Specifications ver.0.1
OP case – Op summary contents go to the referral doctor
IP case- A portion of discharge summary will be sent to referral doctor (internal consensus to be taken from doctors)
Referral notes & documents will appear in doctor dashboard against the particular patient details.
Email/SMS module integration
Provision to send e-mail/SMS to both patient & referral doctor/organization.
Inter module Interactiono ES- Appointment schedulero Appointment management – PRM Website/ portal where patient logs in & hospital representative(PRM
user) receives requests
NOTE- If any Integration needs arise in the future then system should be able to cater to the needs
Alternate / Flexibility Options in the Business Process
-NA-
Outputs System will trigger intimation through ( appointment management –PRM) to various entities including a confirmation email to patient& referral doctor
Messages SMS to concerned people as per the status as per the SMS configuration
Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.12STAFF FEEDBACK ON THE PATIENT
3.12.1 Business Process detail
Description When the user has experienced any negative experience he will communicate it to the staff/perceived reaction of the patient is captured so
For Internal Use Page 153 of 232
MedMantra Software Requirements Specifications ver.0.1
that the perception of the patient can be changed by the end of his transaction. I.e. helping the patient to translate his negative experience into WOW experience.
System should Provide Left menu option of the user screen where they
can select the UHID & enter the feedback & valid dates Until the valid date the feedback is maintained &
displayed on the PATIENT PANEL.
Users with access controlPre – requisites Business Process Details
The feedback is capture by the hospital employee
1. Create a feedback on patient 2.This option would be available on the Left menu option of the user screen where they can select the UHID & enter the feedback & valid dates (this comment is valid up to only current transaction).
2.Feedback entered will appear in patient panel until the valid date this will appear on the PATIENT PANEL.
Inter module interactions
Patient panel in all modules
Alternate / Flexibility Options in the Business Process
-NA-
Outputs Feedback given by the staff will be available in patient panelMessages SMS to concerned people as per the status as per the SMS
configurationException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 154 of 232
MedMantra Software Requirements Specifications ver.0.1
3.12.2 Create Staff Feedback
DescriptionSystem should
Provide Left menu option of the user screen where they can select the UHID & enter the feedback & valid dates
Users with access controlPre – requisites Business Process Details
The feedback is capture by the hospital employee
1. Create a feedback on patient
This option would be available on the Left menu option of the user screen where they can select the UHID & enter the feedback & valid dates (this comment is valid up to only current transaction).
LOV Master for Staff feedback drop down to be maintained.(For easier description & uniformity)
Alternate / Flexibility Options in the Business Process
-NA-
Outputs Feedback given by the staff will be available in patient panelMessages SMS to concerned people as per the status as per the SMS
configurationException handling
-NA-
For Internal Use Page 155 of 232
MedMantra Software Requirements Specifications ver.0.1
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.12.3 View Staff Feedback
Description System should Until the valid date the feedback is maintained &
displayed on the PATIENT PANEL.
Users with access controlPre – requisites Business Process Details
The feedback is capture by the hospital employee
Feedback entered will appear in patient panel until the valid date this will appear on the PATIENT PANEL.
Inter module interactions
Patient panel in all modules
Alternate / -NA-
For Internal Use Page 156 of 232
MedMantra Software Requirements Specifications ver.0.1
Flexibility Options in the Business ProcessOutputs Feedback given by the staff will be available in patient panelMessages SMS to concerned people as per the status as per the SMS
configurationException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.13 Virtual Consultation
3.13.1 Request for Virtual consultation
3.13.1.1 Business ProcessDescription Virtual consultation allows the patient to consult the doctor at his comfort,
or on his choice.
System should allow to1. Receive requests from Patient through SMS/Call/E-mail/website
a. Toll free number/common number can be published in website through which people who like to avail this particular service will make a request or
For Internal Use Page 157 of 232
MedMantra Software Requirements Specifications ver.0.1
b. Website through the patient registers his details including reports , previous summaries etc
2. PRM user receives request & books appointment3. Appointment scheduled &followed up ( Appointment scheduler &
Appointment management (PRM)4. Appointment reminder & follow up 5. Virtual consultation using Skype in Med mantra application
a. Preferred mode in Skype could be only voice call orb. Video call c. For both types conference to include more than 2 people
should also be available. Bridge number to be provided for the third person if the third person wants to join the conversation
6. Virtual consultation recorded & kept as OP record ( e-medical record for future reference)
7. Virtual consultation record will also part of patient record , where the patient can view the record either in through e-mail / web (login /password) in the patient portal/ website of the hospital
8. Should allow the patient to send e-mail of reports which can be appended to the patient record. Or through the website the patient can upload his reports & previous summaries if any .
Users with access controlPre – requisites
Skype integration with med mantra
Business Process Details
1. Request for virtual consultation
a) Request can from website – where the patient requests for appointment with a particular speciality/doctor with the mode of appointment as virtual consultation
b) E-mail request for having a virtual consultation
c) Through call can ask for a consultation
d) Appointment ID is generated by booking appointment .Appointment ID series will be different from normal appointment ID.
e) Also separate link of all virtual consultation for that week is maintained in the appointment management screen in PRM.
2. A programme manager who manages all the requests from web
will receive the virtual consultation list after the request has been made. After an appointment is booked All the virtual requests also come to Appointment management screen. Separate Link will be provided for virtual appointment list, where the special care is taken in booking time & also booked after the payment confirmation is received.
o ES- Appointment schedulero Appointment management – PRM
Website/ portal where patient logs in & hospital representative(PRM user) receives requests
For Internal Use Page 158 of 232
MedMantra Software Requirements Specifications ver.0.1
Alternate / Flexibility Options in the Business Process
-NA-
OutputsMessagesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.13.2 Steps for Virtual consultation using Skype in Med mantra application
Description Virtual consultation allows the patient to consult the doctor at his comfort, or on his choice.
System should allow to send
Skype ID of the doctor to be communicated through SMS/E-mail /call to the patients
While taking request the Skype ID of the customer is also taken
After the confirmation of slot the patient can come & login the Skype start the consultation.
Voice/video recorded & posted as part of EMR.against the OP number
Users with access controlPre – requisites
Skype integration with med mantra
Business Process Details
1. Patients requests for virtual consultation along with his Skype ID through his login & password ( website from hospital)
2. Skype link is provided in the website where they can login /create ID
3. Once request is received the patient co-coordinator/PRM user will schedule an appointment.
4. Payment has to made by the patient against UHID /through payment gate way available for certain locations.
5. Doctor name which needs to be added in Skype is also sent to patient
6. Patients adds doctor Skype ID to his list7. Once appointment scheduled then the doctor also informed &
For Internal Use Page 159 of 232
MedMantra Software Requirements Specifications ver.0.1
reminded about the consultation date & time along with the patient.8. On the given date & time the doctor & patient come together
online 9. The consultation is completed virtually through Skype.10. E-Prescription created from doctor dashboard against the UHID.
The prescription goes as link to the patient & patient takes the print out of it & purchases the medicines.
Patient registered as OP patient so, Op patient list – Right click option to e- prescribes the patient is available. Since patient has website account & login. This e- prescription view & print format reaches the patient in his login as a link which can be printed.
11. E-prescription includes medication name, frequency, duration etc along with the digital signature. Print version has Apollo logo & doctor name & specialty details.
12. Op summary also goes to patient Inbox. Which can be printed13. Consultation is recorded against the OP record. (Will become part
Medical record.14. If more than one consultation is required at a time then the tele-
conference option is sought.
3G ENABLED1. Virtual consultation through mobile with video calling.2. Patient calls & Registers through IVR, selects a
specialist/specialty or IVR routes to paramedics/ medical graduates understand the symptoms & connects them to the specialist.
3. Doctor takes the call & virtual consultation taken4. Virtual consultation recorded & attached to UHID to create
patient record. (Doctor Phone provided by the hospital for giving virtual consultation.)
5. Payment obtained from mobile company .(as per agreement)
Intermodular interactions
o ES- Appointment schedulero Appointment management – PRM
Website/ portal where patient logs in & hospital representative(PRM user) receives requests
External
Website for patients- patient portal
Alternate / Flexibility Options in the Business Process
-NA-
Outputs MessagesException handling
-NA-
For Internal Use Page 160 of 232
MedMantra Software Requirements Specifications ver.0.1
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.13.2.1 E- Prescription
Description Virtual consultation allows the patient to consult the doctor at his comfort, or on his choice.
System should allow to send
Send e- prescription Printable e- prescription for the patient . Should be able to post it against the OP record which the
patient accesses & prints the prescription Or Should be able to send it through email of the patient Doctor should have e- prescribe option against the patient
in the doctor dashboard where he can e- prescribe./ while recording the Op consultation
Users with access controlPre – requisites
Skype integration with med mantra
Business Process Details
Electronic prescribing is a form of computerized physician order entry. Orders are usually placed in the exam room while seeing the patient/ while monitoring patient remotely
1. The prescriber logs on to the system and authenticates their identity. This important step ensures that no one may impersonate an authorized prescriber and generate illegal prescriptions. Authentication required through secure login
2. The prescriber looks up the patient in the system
3. A drug is chosen, with parameters including strength, quantity, directions, and number of refills
4. The patient's active medication list and known allergies are reviewed for potential adverse drug reactions
5. The system may suggest alternative drugs that are either more effective or less costly
6. Select a pharmacy that will process the order, and place the order
7. The order flows over an encrypted connection to the pharmacy. The connection may be directly routed over a Apollo Pharmacy chain such as. Orders take the form of standardized electronic messages that both the prescriber's system and the pharmacist's system must implement.
For Internal Use Page 161 of 232
MedMantra Software Requirements Specifications ver.0.1
8. The order appears in the pharmacists computer system, where it may be filled.
9. The patient shows up at the pharmacy to pick up and pay for their medications.
New prescription orders are not the only type of message that can flow over the network connection. Other types of messages may include:
Notice from the pharmacist that the order has been filled or refilled
Request from the pharmacist for additional refills, and response from the doctor either authorizing or denying the request
Change the prescription parameters
Cancel the prescription
Alternate / Flexibility Options in the Business Process
-NA-
Outputs MessagesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.14 Enabling External entities
3.14.1 Business process details
Description Enabling your external entities your patients/ devices which help the patient to get treatment with out actually visiting the hospital or even before he visit the hospital.
Enabling external entities in special conditions
1. Remote health monitoring where the patient is monitored from home /when he away from the hospital by the hospital doctor.
2. Tele consultations through Telemedicine technology etc will be part of
For Internal Use Page 162 of 232
MedMantra Software Requirements Specifications ver.0.1
the Medical record of the patient. External software have to be integrated to maintain the medical record of the patient be it remotely monitored patient or consultation.
3. Any such External entities which requires to be integrated as decided by management from time to time
Once patient requests for remote health monitoring services- project /Programme manager registers the details & creates patient profile. After the quote has been sent for the service charges . he can either accept /reject case. Accepts when the payment has been made/ agreed to provide services for that particular type of device.Once he accepts the patient he can assign a doctor who will be managing the case. Project/Programme manager can also login & view the patient monitor details along with the closing date of agreement.When ever the closing date is nearing then the patient is alerted for renewal process.( agreement has to be renewed annually. Then 1 month or x days before the agreement closure date an email reminder is sent & followed for renewel.
Users with access controlPre – requisites
Integration with medical device which monitors patient vitals & other paramters
Integration with telemdeicne software with e-HISBusiness Process Details
1. Remote health monitoringa) All requests received through web/ any other sources will
be received by the project manager .b) After receiving the request the patient details are
registered into the system as prospective customer. Details should include- Demographic details, past investigation details& Treatment details, Device details- Health monitoring devices details such as company name & parameters it monitors (heart rate, BP, ECG, SPo2 etc)
c) Based on the details provided & device which is being used- the device integration requirements are assessed.
d) Depending on the above factors the service charges required are sent to the customer.
e) If the customer is willing to take up the service then payment is made to hospital against the service.
f) Patient enrolled as part of the programme as per the terms & conditions agreed.
g) Doctor assigned for that particular patient who gets updates from the application whenever there is deviation & can also view in login the entire record of the patient .- Recent & old details along with clinical history available to correlate with the findings & suggest the patient.
h) The patient monitored remotely- Based on the algorithm for each parameter the application will detect deviation from the standard values & alerts the patients & doctor.
i) Doctor can prescribe the patient using e- prescribe option in his login. this e-prescription can be printed by the patient to buy the medicine.
j) In case of emergencies the emergency department is also alerted along with the doctor, Ambulance can be sent to bring the patient to the hospital.
For Internal Use Page 163 of 232
MedMantra Software Requirements Specifications ver.0.1
k) Detailed clinical history , prescription history along with the device recording history will be viewable.
l) E- prescribe option available where they prescribe medicine & patient can view & print it.
Application based on the algorithm sends alerts to emergency also when ever the threshold value reaches an alarming value.an flow over the network connection. Other types of messages may include:
Notice from the pharmacist that the order has been filled or refilled
Request from the pharmacist for additional refills, and response from the doctor either authorizing or denying the request
Change the prescription parameters
Cancel the prescription
Business rules
o All latest values will appear in the dashboard. If want to view the previous recording they can view on monthly/ weekly/daily recording by selecting the appropriate period.
o E- prescrption option to be available for remotely monitored & tele consultation patients(refer to E prescrption process)
Telemdicine
Highlighting the range of customisations require dfor integrating Telemedine software
• DICOM support• Support for specific HL7 messaging.• Customized generation and printing of forms that include various parameters, reports, etc.• Specific authentication support including Smart cards, Biometrics, etc.• Integration with existing HIS, PACS or other Clinical Support System.• Interface with various specialty devices.
Highlighting the range of customisations required for conducting tele consultaion, tele radiology, tel pathology consulattiona etc
• DICOM support• Support for specific HL7 messaging.• Customized generation and printing of forms that include various parameters, reports, etc.• Specific authentication support including Smart cards, Biometrics, etc.• Integration with existing HIS, PACS or other Clinical Support System.• Interface with various specialty devices.
Alternate / -NA-
For Internal Use Page 164 of 232
MedMantra Software Requirements Specifications ver.0.1
Flexibility Options in the Business ProcessOutputs Messages SMS/ Email to patient & doctor when ever a deviation is observed
In emergency situation- alert goes to ambulance& emergency department also.
SMS/Email to patient & consultants when ever tele consultation is booked.Exception handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.15 Health Tips & birthday /anniversary wishes
3.15.1 Business ProcessDescription Health tips
SMS Gateway (aggregator) embedded in solution • Support for local long codes • Support for local short codes
• Scheduled/calendar based events Scheduled healthcare tips and reminders based on specified date (e.g. due date for pregnant mother) .If already there is a third party / partner group software is available to send health tip .If need arises integration with e- HIS can be taken up later
System should be able to send the birthday/ anniversary wishes everyday at particular time (trigger)
Users with access control
PRM Users
Pre – requisites
Health tip content has to come from authorized person
Business Process Details
1. Search for eligible members & ADD members for whom the message is intended- Criteria is based on
a. Ageb. Genderc. Diagnosis- search diagnosisd. Procedure/treatment – search procedure/treatment list e. Any other criteria – Which business may introduce at later stage
For Internal Use Page 165 of 232
MedMantra Software Requirements Specifications ver.0.1
2. Option to add multiple combination of criteria to be available3. Option to add diagnosis or treatment/procedure to be available4. Option to select all patient without any criteria also to be available5. Select the target email ID’s/ Phone numbers6. Select & enter the text or browse option to upload any article/ HTML address
can be entered – content of the article will go as body of the message7. Send & view the preview of the message to any email ID8. Edit message after the preview if required 9. Send message to the target audience
Business ruleo When we are selecting target audience based on disease the person who
is having more than one disease should also be selected as part of this camping .Say for example if disease is the criteria and Diabetes has been selected then system should not restrict the message if the person has any other disease.
o According to registration record- Every day system should trigger for Birth day /Anniversary message( Default messages) to be sent to all patients whose birthday or anniversary falls on that particular date.
o Based on the birthdate of babies born in the hospital & vaccination schedules planned for- Tips /reminders can be sent for vaccination of babies
o Search by selected criteria –
1.All the patients falling under the criteria & with Email /Mobile number only will be selected will be stored at the back end ADD customer to whom tip/Message has to be sent 2. Duration to be restricted to x days
2. Message – 1. Text or upload /Import options to be provided. 2. Text can send stored message by clicking on Edit . Or can send a new message by selecting add new. 3 . Upload content – size limitation to be discussed with technically team 4. Import HTML- HTML page can be imported from authentic sources & can sent as an E-mail. 5. other options disabled if the text message is selected. 6.Send it by date & time option to be added. 7.From the selected criteria /Excel also -Only select patients list with Mobile no. & E-mail ID
Intermodule interactions
Diagnosis search could be directly fetched from the wards module final/Provisional diagnosis for those patients who have at least one IP/OP episode. For Phone number and other demographic details could be fetched directly from the registration module
Alternate / Flexibility Options in
NA
For Internal Use Page 166 of 232
MedMantra Software Requirements Specifications ver.0.1
the Business ProcessOutputs
Messages Birthday/Anniversary wishesException handling
-NA-
Error Reporting
-NA-
Scheduling -NA-Trigger InTrigger OutAssumptions
3.15.2 Select Target Audience ADD MEMBERSDescription ADD MEMBERS- Based on search criteria the members list is populated &
selected to insert those addresses in TO field in e-mail. OR all mobile numbers are selected for which the message needs to be sent.
Users with access control
PRM Users
Pre – requisites
Business Process Details
1. Search for eligible members & ADD members for whom the message is intended- Criteria is based on
a. Ageb. Genderc. Diagnosis- search diagnosisd. Procedure/treatment – search procedure/treatment list e. Any other criteria – Which business may introduce at later stage
2. Option to add multiple combination of criteria to be available3. Option to add diagnosis or treatment/procedure to be available4. Option to select all patient without any criteria also to be available5. Select the target email ID’s/ Phone numbers6. Select & enter the text or browse option to upload any article/ HTML
address can be entered – content of the article will go as body of the message
Business ruleo When we are selecting target audience based on disease the person
who is having more than one disease should also be selected as part of this camping .Say for example if disease is the criteria and Diabetes has been selected then system should not restrict the message if the person has any other disease.
o According to registration record- Every day system should trigger for Birth day /Anniversary message( Default messages) to be sent to all patients whose birthday or anniversary falls on that particular date.
o Based on the birthdate of babies born in the hospital & vaccination schedules planned for- Tips /reminders can be sent for vaccination of
For Internal Use Page 167 of 232
MedMantra Software Requirements Specifications ver.0.1
babies
Intermodule interactionsDiagnosis search could be directly fetched from the wards module final/Provisional diagnosis for those patients who have at least one IP/OP episode. For Phone number and other demographic details could be fetched directly from the registration module
Alternate / Flexibility Options in the Business Process
NA
Outputs
MessagesException handling
-NA-
Error Reporting -NA-Scheduling -NA-Trigger InTrigger OutAssumptions
3.15.3 Create Message & SEND
Draft UI for Entering & sending Health Tip
Description Once Target Audience are selected & added to the TO field then the Authorized content of the Health tip is gathered from reliable source both in house doctors or standard health article websites etc, is sent to Target audience
Users with access control
PRM Users
Pre – requisites Health tip content has to come from authorized person
Business Process Details
1. Select the target email ID’s/ Phone numbers2. Select & enter the text or browse option to upload any article/ HTML
address can be entered – content of the article will go as body of the message
Business ruleo According to registration record- Every day system should trigger for
Birth day /Anniversary message( Default messages) to be sent to all patients whose birthday or anniversary falls on that particular date.
o Based on the birthdate of babies born in the hospital & vaccination schedules planned for- Tips /reminders can be sent for vaccination of
For Internal Use Page 168 of 232
MedMantra Software Requirements Specifications ver.0.1
babies.
1.Search by selected criteria – 1.All the patients falling under the criteria & with Email /Mobile number only will be selected will be stored at the back end ADD customer to whom tip/Message has to be sent 2. Duration to be restricted to x days 2. Message – 1. Text or upload /Import options to be provided. 2. Text can send stored message by clicking on Edit . Or can send a new message by selecting add new. 3 . Upload content – size limitation to be discussed with technically team 4. Import HTML- HTML page can be imported from authentic sources & can sent as an E-mail. 5. other options disabled if the text message is selected.6.Send it by date & time option to be added. While sending the health tip/ message the system should ask for date & time at which the tip is to be sent7. Pop up once the message/e-mail is sent to the recipients 8.From the selected criteria /Excel also -Only select patients list with Mobile no. & E-mail ID
Alternate / Flexibility Options in the Business Process
NA
Outputs
MessagesException handling
-NA-
Error Reporting -NA-Scheduling -NA-Trigger InTrigger OutAssumptions
3.15.4 Reports
Reports
1. Periodic reports on Successful transactions
2. Periodic reports on Undelivered transaction
3.16 International Patient management
3.16.1 Business process Description
Description
For Internal Use Page 169 of 232
MedMantra Software Requirements Specifications ver.0.1
The international patients division of Apollo Hospitals works towards providing better services to the international patients from across world. Most of the patients interact with either call center, the International patient department or through Location wise in-charge details, phone numbers & email ID’s available on the websites.
Benefits of using PRM module.
1. Multiple channels of enquiry are not integrated hence results cannot be delivered in a single report. Using HIS No matter which channels you use —Web, telephone, or paper—all the results can be delivered in a single report so you don’t lose valuable insight in silos.
2. Tracking each individual case till closure becomes difficult as the TAT for these types of patients are long, also can lose track which huge volume of enquiries/follow -ups.
3. Default message s can be set up for referral or regular message (if any standard message formats are available. default email ID’s/address can be stored
4. E-mail communication against a single case can be tracked for future references/follow ups.
5. All international Credit approving details are stored which can used for quick reference/follow ups. Also this will help in analyzing the trends etc.
6. Unique case ID i.e. IPS ID is created for each international patient enquiry who is interested in coming to the hospital.
Users with access control
1.International patient services Department 2. Any PRM user
Pre – requisites Business Process Details System should be able to generate Patient Work list
Work list should include all the international customer care queries through various sources
a) All international enquiries received by call center ( customer type is international in enquiry form)
b) Enquiries received through website where location is outside India.c) Enquiries received to email ID’s mentioned in the website integrated with E-
HIS(PRM) d) For all the above sources the enquiry comes into work list & IPS ID Created
after the initial follow upe) If any other source then IPS ID can be created to insert record in the work list
by using create IPS ID directly.
a. Patient Work listb. Create IPS IDc. Pre-visit follow up
i. Follow –up of the query for visiting the hospitalii. Request form filled & sent to the concerned authority ( credit
company/Govt )iii. Reply received & payment/credit details updatediv. Plan for admission.-bed reservation link
For Internal Use Page 170 of 232
MedMantra Software Requirements Specifications ver.0.1
v.Preference capturedvi. Patient visits
d. Post-visit follow –upi. Arrival record sent to the concerned authority ( credit
company/Govt )ii. Additional request form sent if requirediii. Payment details updated.iv. Closure of visit
Request form filled & sent to the concerned authority1.Request form – Should be able to send Email./Fax to the Credit Organization in case of credit patients. To Patient in case of Cash patient etc – the PDF form should be printable with Apollo Logo, Disclaimer .2.Request form Id can be created. Also History of request forms against IPS ID. to be maintained
Creation of IPS ID
a) The details which are been captured previously in the enquiry form will be auto populated. (Patient name/age/contact details etc.)
b) Other details are filled by International patient department personnel after the initial follow up activity. If the patient shows some interest in utilizing our hospital records further details will be asked. For example Passport no. & visa validity details are captured at this stage.
c) IPS ID has to be linked to enquiry id of the patient.d) So the form is filled up in stages as when details are available. But IPS ID
created with the basic details.
System should be able display IPS ID, enquiry id, UHID, Authority, expected date with an option to declare Arrived or not with status being defined in Masters.
It should also have a link to Ambulance and availability of vehicle and driver depending upon the urgency and necessity of patient.
System should be able to capture the mode of accommodation, preferred mode of transport, capture local sim card details and if accommodation is not according to the space suggested then the same amount shouldn’t be part of patient charge while settlement happens.
Search filtration based upon status should be available and to be tagged to status wise login id to be linked.
Dash Board should have the option to create IPS ID, follow up and view complete details.
System should have flexibility to upload scanned document related to Past patient records.
System should also have the flexibility to send Reminders for Follow ups. System to allow access to fill Request form to specific Roles so that the
same can be sent to Concerned Authority/ Credit Agency for necessary corrective measures.
Follow up system should be able to send reminders through different media like web, sms and fax etc.
System should be able to generate the approximate expenditure for the proposed length of stay quotation wherein authorized signatory designation & signature should be in built and changeable.
System should have linkage to Billing and CRM wherein location wise details approximate cost can be provided.
After arrival of the patient the system should be able to display estimated cost vis a vis Deposit and Credit limit.
System should be capable to send alert to concerned persons in case estimated cost is more than the deposit & authorized credit limit.
For Internal Use Page 171 of 232
MedMantra Software Requirements Specifications ver.0.1
Business Rule:
Once IPS id is created with patient details the information can be updated. There will be unique Enquiry ID against IPS ID. For creation of IPS ID enquiry id is not a prerequisite. Delisted once line item is closed/No show is marked .Closure option in post arrival
dashboard. The moment estimated cost goes beyond the deposit and credit limit then it should
throw an alert to raise a request form.
Alternate / Flexibility Options in the Business ProcessOutputs
MessagesException handling
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 172 of 232
MedMantra Software Requirements Specifications ver.0.1
3.16.2 Patient Work list
3.16.2.1 Business process
DescriptionThe international patients division of Apollo Hospitals works towards providing better services to the international patients from across world. Most of the patients interact with either call center, the International patient department or through Location wise in-charge details, phone numbers & email ID’s available on the websites.
Benefits of using PRM module.
1. Multiple channels of enquiry are not integrated hence results cannot be delivered in a single report. Using HIS No matter which channels you use —Web, telephone, or paper—all the results can be delivered in a single report so you don’t lose valuable insight in silos.
2. Tracking each individual case till closure becomes easier
3. Default message s can be set up for referral or regular message (if any standard message formats are available. default email ID’s/address can be stored
4. E-mail communication against a single case can be tracked for future references/follow ups.
5. All international Credit approving details are stored which can used for quick
For Internal Use Page 173 of 232
MedMantra Software Requirements Specifications ver.0.1
reference/follow ups. Also this will help in analyzing the trends etc.
6. Unique case ID i.e. IPS ID is created for each international patient enquiry who is interested in coming to the hospital.
Users with access control
1.International patient services Department 2. Any PRM user
Pre – requisites Business Process Details System should be able to generate Patient Work list for pre visit follow up
Work list should include all the international customer care queries through various sources
f) All international enquiries received by call center ( customer type is international in enquiry form)
g) Enquiries received through website where location is outside India.h) Enquiries received to email ID’s mentioned in the website integrated with E-
HIS(PRM) i) For all the above sources the enquiry comes into work list & IPS ID Created
after the initial follow upj) If any other source then IPS ID can be created to insert record in the work list
by using create IPS ID directly. System should be able display IPS ID, enquiry id, UHID, Authority,
expected date with an option to declare Arrived or not with status being defined in Masters.
It should also have a link to Ambulance and availability of vehicle and driver depending upon the urgency and necessity of patient.
System should be able to capture the mode of accommodation, preferred mode of transport, capture local sim card details and if accommodation is not according to the space suggested then the same amount shouldn’t be part of patient charge while settlement happens.
Search filtration based upon status should be available and to be tagged to status wise login id to be linked.
Dash Board should have the option to create IPS ID, follow up and view complete details.
System should have flexibility to upload scanned document related to Past patient records.
System should also have the flexibility to send Reminders for Follow ups. System to allow access to fill Request form to specific Roles so that the
same can be sent to Concerned Authority/ Credit Agency for necessary corrective measures.
Follow up system should be able to send reminders through different media like web, sms and fax etc.
System should be able to generate the approximate expenditure for the proposed length of stay quotation wherein authorized signatory designation & signature should be in built and changeable.
System should have linkage to Billing and CRM wherein location wise details approximate cost can be provided
Business Rule:
Once IPS id is created with patient details the information can be updated. There will be unique Enquiry ID against IPS ID. For creation of IPS ID enquiry id is not a prerequisite.
For Internal Use Page 174 of 232
MedMantra Software Requirements Specifications ver.0.1
Once status is closed then no further action is possible in Dash Board. The moment estimated cost goes beyond the deposit and credit limit then it should
throw an alert to the concerned login id (Configurable) to raise a request form.
NOTE- ONCE IPS ID CREATED , REQUEST FORM OPTION TO APPEAR
Alternate / Flexibility Options in the Business ProcessOutputs
MessagesException handling
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.16.2.2 Input attributes
Attribute Name
Description
Data Type
Length
List of values
Conditions Logic
Validation
Compliance Remarks
IPS ID IPD ID is created after filling the IPS ID form
Number
10 IPs ID created after filling up the form
UHID Patient UHID
Varchar 10
Patient Name
Patients Name
Varchar 50
Billing Type
Credit or cash
Varchar
10 Billing Type LOV
Country Country Name
Varchar
20 Country LOV in registration
Reffered by
Referral Doctor Name
Varchar 50
Credit authority
Who approves the credit for patient
Varchar
50 IPS Credit organsiation LOV
Date of When the Date
For Internal Use Page 175 of 232
MedMantra Software Requirements Specifications ver.0.1
appointment
patient expected to come as OP patient
& time
Date of admission
When the patient come as IP patient
Date& time
Arrival date& time
When the patient expected to come as IP patient
Request form
Link of request form filled
Estimated cost
As in Request form
Number
15
Deposit/Credit limit
As in billing deposit + Credit amount
Number
15
Status Status of the worklist item
Varchar
15
3.16.3 Create IPS ID
Create IPS iD screen lay out
3.16.3.1 Business process details
For Internal Use Page 176 of 232
MedMantra Software Requirements Specifications ver.0.1
Description IPS ID – International Patient services ID is created for each enquiry received through various sources
The enquiry can come through call centre with enquiry ID For Enquiries received through various other sources – IPS iDis created
directed directly
.
Users with access control
1.International patient services Department 2. Any PRM user
Pre – requisites Business Process Details
Creating IPS ID for each enquiry
a) The details which are been captured previously in the enquiry form will be auto populated.(patient name/age/contact details etc
b) Other details are filled by International patient department personnel after the initial follow up activity. If the patient shows some interest in utilizing our hospital records further details will be asked. For example Passport no. & visa validity details are captured at this stage.
c) So the form is filled up in stages as when details are available. But IPS ID created with the basic details.
d) Later it can updated as per the information availability..
Business Rule:
Once IPS id is created with patient details the information can be updated. There will be unique Enquiry ID against IPS ID. For creation of IPS ID enquiry id is not a prerequisite. Once status is closed then no further action is possible in Dash Board. The moment estimated cost goes beyond the deposit and credit limit then it should
throw an alert to the concerned login id (Configurable) to raise a request form.
Alternate / Flexibility Options in the Business ProcessOutputs
MessagesException handling
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 177 of 232
MedMantra Software Requirements Specifications ver.0.1
3.16.3.2 Input attributes
Attribute Name
Description
Data Type
Length
List of values
Conditions Logic
Validation
Compliance Remarks
IPS ID IPD ID is created after filling the IPS ID form
Number
10 IPs ID created after filling up the form
UHID Patient UHID
Varchar 10
Patient Name
Patients Name
Varchar 50
Patient contact No
Phone number Numbe
r 15
Patient e-mailID
emailID Varchar 50
Billing Type
Credit or cash
Varchar
10 Billing Type LOV
Age Patients age
Number
2
Country Country Name
Varchar
20 Country LOV in registration
Referred by
Referral Doctor Name
Varchar 50
Credit authority
Who approves the credit for patient
Varchar
50 IPS Credit organization LOV
Date of appointment
When the patient expected to come as OP patient
Date & time
Date of admission
When the patient come as IP patient
Date& time
Arrival date& time
When the patient expected to come as IP patient
Request form
Link of request form filled
For Internal Use Page 178 of 232
MedMantra Software Requirements Specifications ver.0.1
Estimated cost
As in Request form
Number
15
Deposit/Credit limit
As in billing deposit + Credit amount
Number
15
Status Status of the work list item
Varchar
15
Visa valid date
Patient vis a details
Date
Passport Number
Pass port Number
Number
Treatment Details
Patient proposed treatment details
Varchar
200
Specialty
Apollo doctor specialty
Varchar
50 Specialty LOV
Doctor Name
Apollo doctor name
Varchar
50 Doctor name LOV
Doctor contact details
EMialID/Phone number
Varchar/Numerical
50
For Internal Use Page 179 of 232
MedMantra Software Requirements Specifications ver.0.1
3.16.4 Request form
For Internal Use Page 180 of 232
MedMantra Software Requirements Specifications ver.0.1
Draft UI for Request Form
3.16.4.1 Business process details
Description IPS ID – International Patient services ID is created for each enquiry received through various sources
o Request form is sent by the international patient department to the referral organization or the patient (in case of cash patients)
o Request form though filled by the doctor – The IPS department fills it in the system
System should be capable to
o Automate request form
o Once request form is filled the same should be sent via FAX or E-mail( integration TBD)
o While sending /On the print- It should display Apollo logo, doctor name, digital signature& disclaimer.
o Master screen to store all Credit approving authority – Email Id & phone no.
o To &for communication history to be stored & link of details to be provided.
For Internal Use Page 181 of 232
MedMantra Software Requirements Specifications ver.0.1
Users with access control
1.International patient services Department 2. Any PRM user
Pre – requisites Business Process Details o Request form is sent by the international patient department to the
referral organization or the patient (in case of cash patients)
o Request form though filled by the doctor – The IPS department fills it in the system
Request form contains the following details From doctor/Team- doctor name who has filled the form Patient details- Name, age Referral details- referral doctor/organization name Report s which have been sent by patient should also be sent via e-mail as
an attachment Planned treatment/procedure Estimated cost Estimated no. of days Inclusion & exclusions o the cost No of days in post op period Any other information Appointment date
Business Rule:
Once saved request Number against the IPS ID is stored. If the second request form goes during post visit follow up then the first request form number to be displayed for reference.
Alternate / Flexibility Options in the Business ProcessOutputs
MessagesException handling
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.16.5 Follow up of International Patients
For Internal Use Page 182 of 232
MedMantra Software Requirements Specifications ver.0.1
Follow up set up
3.16.5.1Business process detailsDescription IPS ID – International Patient services ID is created for each enquiry received through
various sources
From the time Enquiry is received the patient /referral organization/referral doctors followed up for various reasons
For receiving complete details of the patient
For sending request form- documents needed will be collected
Request form sent & acknowledgement
Once credit letter is received follow up for
o Preferences- Accommodation, Food, Transport details etc
o Date of arrival
o Flight details are also noted down
Users with access control
1.International patient services Department 2. Any PRM user
Pre – requisites
For Internal Use Page 183 of 232
MedMantra Software Requirements Specifications ver.0.1
Business Process Details From the time Enquiry is received the patient /referral organization/referral doctoris
followed up for various reasons
For receiving complete details of the patient
For sending request form- documents needed will be collected
Request form sent & acknowledgement
Once credit letter is received follow up for
o Preferences- Accommodation, Food, Transport details etc
o Date of arrival
Flight details are also noted down
Business Rule:
Follow up set similar to appointment follow up Follow up history to be maintained To & fro communication through E-mails to be tracked down for each individual patient.
Alternate / Flexibility Options in the Business ProcessOutputs
MessagesException handling
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 184 of 232
MedMantra Software Requirements Specifications ver.0.1
3.16.6 Complete details
Draft UI – complete details
3.16.6.1Business process details
Description Complete details of the patient are captured once the patient decides to come to the hospital
Once credit letter is received follow up for
o Preferences- Accommodation, Food, Transport details etc
o Date of arrival
o Flight details are also noted down
Users with access control
1.International patient services Department 2. Any PRM user
Pre – requisites Business Process Details From the time Enquiry is received the patient /referral organization/referral doctors
followed up for various reasons
For receiving complete details of the patient
For Internal Use Page 185 of 232
MedMantra Software Requirements Specifications ver.0.1
For sending request form- documents needed will be collected
Request form sent & acknowledgement
Once credit letter is received follow up for
o Preferences- Accommodation, Food, Transport details etc
o Date of arrival
No. of attendants accompanying the patient
FRRO visit details- Foreign Regional Registration Office which verify the entry into a country. If the visa mandates to visit FRRO then the patient visits FRRO within 14 days of visit.
Type of visa on which they reached hospital.
Flight details are also noted down
1.Complete details are saved & updated as when information is received from the patient end. Flight details, airlines name can also be added to the details2.Upon clicking Request form in this page – previous request details are also seen (history is also maintained)
Business Rule:
Should be able save, confirm the arrival. mark No show Should be able to book No show – patient did not turn up after x days of expected arrival
dateAlternate / Flexibility Options in the Business ProcessOutputs
MessagesException handling
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 186 of 232
MedMantra Software Requirements Specifications ver.0.1
3.16.6.2Input attributesAttribute Name
Description
Data Type
Length
List of values
Conditions Logic
Validation
Compliance Remarks
IPS ID IPD ID is created after filling the IPS ID form
Number
10 IPs ID created after filling up the form
UHID Patient UHID
Varchar 10
Patient Name
Patients Name
Varchar 50
Patient contact No
Phone number Numbe
r 15
Patient e-mailID
emailID Varchar 50
Billing Type
Credit or cash
Varchar
10 Billing Type LOV
Age Patients age
Number
2
Country Country Name
Varchar
20 Country LOV in registration
Referred by
Referral Doctor Name
Varchar 50
Credit authority
Who approves the credit for patient
Varchar
50 IPS Credit organization LOV
Date of appointment
When the patient expected to come as OP patient
Date & time
Date of admission
When the patient come as IP patient
Date& time
Arrival date& time
When the patient expected to come as IP patient
Request form
Link of request form filled
Estimated cost
As in Request form
Number
15
Deposit/Credit limit
As in billing deposit +
Number
15
For Internal Use Page 187 of 232
MedMantra Software Requirements Specifications ver.0.1
Credit amount
Status Status of the work list item
Varchar
15
Visa valid date
Patient vis a details
Date
Passport Number
Pass port Number
Number
Treatment Details
Patient proposed treatment details
Varchar
200
Specialty
Apollo doctor specialty
Varchar
50 Specialty LOV
Doctor Name
Apollo doctor name
Varchar
50 Doctor name LOV
Doctor contact details
Email ID/Phone number
Varchar/Numerical
50
Room type
Varchar
50
Room No
Number
10
Check in date
Date & time
Check out dtae & time
Date& time
Expected arrival date &time
Date& time
Guest house name
Varchar
Guest house LOV
Travel prefrence
varchar
Travel prefernce LOV
Company name
Credit company name
Varchar
20 Auto populated from credit approving authority
Approve d amount
Number/varcahra
20
Payment
Varchar
20
For Internal Use Page 188 of 232
MedMantra Software Requirements Specifications ver.0.1
methodDeposit details
Number
10 Updated from billing
3.16.7 Post visit follow up
Draft UI for Post Arrival Dashboard
3.16.7.1Business process details
Description o Once patient reaches the hospital then the work list item moves into the post visit follow up
System should manage
The movement of work list list item from pre to post visit follow up dashboard based on validation provided by the business
Users with access control
1.International patient services Department 2. Any PRM user
Pre –
For Internal Use Page 189 of 232
MedMantra Software Requirements Specifications ver.0.1
requisites Business Process Details
a. Post-visit follow –upi. Arrival record sent to the concerned authority ( credit
company/Govt )ii. Additional request form sent if requirediii. Payment details updated.iv. Closure of visit
i. Arrival record
a) Arrival record is sent after the patient arrives at hospital. This is mandatory for certain country authorities (credit approving- ministries/embassies)
b) Patient basic details such as Name/Hospital ID(UHID) , OP/IP no., Room No., Diagnosis, Consultant, Passport no., visa No & date of expiry, DOA are captured
c) Attendant record - Attendant Name, Passport no., visa No & date of expiry, are captured
d) Any additional remarks are noted.
e) This document should be printable & should be integrated with fax /email to send & receive the reply.
ii. Request form- If any change in treatment then additional request form will be sent & further enhancement of approved amount is obtained. Follow up required will be co-ordinate by the department.
iii. Payment details- are updated as per the enhancement/credit letter
iv. Closure of visit- Once patient checked out as inpatient/out patient the visit is closed . same patient visits again the previous visit history should be viewable.
Business Rule: Should be able save, confirm the arrival Should be able to book No show – patient did not turn up after x days of expected arrival
dateAlternate / Flexibility Options in the Business ProcessOutputs
MessagesException handling
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
For Internal Use Page 190 of 232
MedMantra Software Requirements Specifications ver.0.1
3.16.8 Arrival Record
3.16.8.1 Business Process DetailDescription Arrival record is sent after the patient arrives at hospital. This is mandatory for certain
country authorities (credit approving- ministries/embassies)
Users with access control
1.International patient services Department 2. Any PRM user
Pre – requisites Business Process Details
i. Arrival record
a) Arrival record is sent after the patient arrives at hospital. This is mandatory for certain country authorities (credit approving- ministries/embassies)
b) Patient basic details such as Name/Hospital ID(UHID) , OP/IP no., Room No., Diagnosis, Consultant, Passport no., visa No & date of expiry, DOA are captured
c) Attendant record - Attendant Name, Passport no., visa No & date of expiry, are captured
For Internal Use Page 191 of 232
MedMantra Software Requirements Specifications ver.0.1
d) Any additional remarks are noted.
e) This document should be printable & should be integrated with fax /email to send & receive the reply.
Business Rule: Should be able save, confirm the arrival
Alternate / Flexibility Options in the Business ProcessOutputs
MessagesException handling
Error Reporting
-NA-
Scheduling -NA-Trigger In -NA-Trigger Out -NA-Assumptions -NA-
3.16.8.2 Input attributesAttribute
NameDescriptio
nDat
a Typ
e
Length
List of values
Conditions Logic
Validation
Compliance Remarks
Patient identifier
Patient identifier
varchar
10 IPs ID created after filling up the form
UHID Patient UHID
Varchar 10
Patient Name
Patients Name
Varchar 50
Gender Male or female
Varchar 10
Consultant Varc
har 50
Consultant name Lov
As in HR
Diagnosis Varchar
100 diagnosis
As in wards
Age Patients age
Number
2
Country Country Name
Varchar
20 Country LOV in
For Internal Use Page 192 of 232
MedMantra Software Requirements Specifications ver.0.1
registration
Visa valid date
Patient vis a details
Date
Visa valid date
Visa No Patient vis a details
Number
20
Date of expiry
When the vis aexpires
Date & time
Arrival date& time
When the patient expected to come as IP patient
Passport number
Varchar
20
Attendeent Name
Attendent name
Varchar 50
Gender Male or female
Varchar 10
Age Patients age
Number
2
Visa valid date
Patient vis a details
Date
Visa valid date
Visa No Patient vis a details
Number
20
Date of expiry
When the visa expires
Date & time
Passport number
Varchar
20
3.17 Constraints and Limitations
3.18 ReportsReport ID Report Name Report description /
PurposeLogic Applicability
AT_R_01 Appointment Reports
List of appointment taken patients
AT_R_02 Post visit follow-up Reports
List of patients advised by Doctor to visit the hospital
AT_R_03 Report on No-show Patients
List of no-show(not turned) patients to the hospital
AT_R_04 Report on Blood Donors
List of Blood Donors who donated blood in the past
AT_R_05 Report on List of patients who
For Internal Use Page 193 of 232
MedMantra Software Requirements Specifications ver.0.1
Prescription follow-up
has to purchase prescribed medicine
AT_R_06 Report on Wellness follow-up
List of patients who has to visit the wellness department
AT_R_07 Report on Disease Management Program follow-up
List of patients who has to visit for DMP
AT_R_08 Appointment Reports
List of confirmed patients to visit the hospital on appointment date
AT_R_09 Appointment Reports
List of Re-scheduled patients
AT_R_10 Appointment Reports
List of appointment cancelled patients
AT_R_11 Appointment Reports
List of patients who booked the appointment
AT_R_12 Appointment Reports
List of patients who booked the appointment on doctors advised date
AT_R_13 Appointment Reports
List of patients who booked the appointment, but not on doctors advised date
AT_R_14 Appointment Reports
List of patients who rejected to take appointment for re-visit
AT_R_15 Appointment Reports
List of no-show patients who booked the appointment
AT_R_16 Appointment Reports
List of no-show patients who rejected to take appointment for re-visit
AT_R_17 Blood Donation Reports
List of Blood Donors who donated blood and took appointment for blood donation
AT_R_18 Blood Donation Reports
List of Blood Donors who donated blood and rejected to take appointment for blood donation
AT_R_19 Report on Prescription follow-up
List of patients who accepted to purchase prescribed medicine
AT_R_20 Report on Prescription follow-up
List of patients who rejected to purchase prescribed medicine
AT_R_21 Report on Prescription follow-up
List of patients who purchased prescribed medicine
AT_R_22 Report on Enquiries List of queries answered/rejected by the PRM, when a attendant/relative of patient is enquired
AT_R_23 Report on intimation of emergency patient condition to attendant/corporate
List of patients, whose condition is intimated to the attendant/corporate
AT_R_24 Report on FeedbackThis is the report, which can be
For Internal Use Page 194 of 232
MedMantra Software Requirements Specifications ver.0.1
accessed by their respective departments.
AT_R_25 Report on FeedbackThis is the report generated in the Pie charts/bar graphs, which can be accessed by their respective departments
AT_R_26 Report on Complaints
This is the report, which can be accessed by their respective departments.
AT_R_27 Report on Complaints
This is the report generated in the Pie charts/bar graphs, which can be accessed by their respective departments
AT_R_28 Report on Counseling
List of patients who are counseled
AT_R_29 Report on Counseling
List of patients attendants who are counseled
AT_R_30 Report on Wellness List of patients who attended wellness
AT_R_31 Report on Complaints
This is the report on complaints which is sent to the respective departments
AT_R_32 Report on Feedback This report can be accessible by the senior management/top level management
AT_R_33 Report on Complaints
This report can be accessible by the senior management/top level management
AT_R_34 Report on Follow-ups
This report can be accessible by the senior management/top level management
AT_R_35 Report on Appointments Alerts
Number of alerts received from the appointments module
AT_R_36 Report on Mails List of patients to whom the mails should be sent
AT_R_37 Report on Wellness List of patients who are not visited the wellness center on the visit date
For Internal Use Page 195 of 232
MedMantra Software Requirements Specifications ver.0.1
3.17 User Roles Matrix
Sr. No. User Role Department Sub Process Code
Access Rights
Remarks
1 follow up activities
Call centre Appointment
Enquiry
No show follow up
Post visit follow up
Blood donor follow up
Prescription follow up
Wellness follow up
Clinical trail follow up
F
2 PRM executive_ Feedback
CRM Cell/ Customer intelligence
Feedback capture
Feedback executive dashboard
I/U
3 PRM- Department HOD_ Feedback
HOD of respective department
Action on Feedback
R/U
4 PRM Admin Customer intelligence
Feedback Management
Feedback review & closure
F
5 Remote Assistance
Doctors Remote health monitoring
Virtual consultation
6
Consultants in-house
Respective Consultants
PRM F
7 Nurse-Wards Wards PRM R
8 Nurse-Emergency
Emergency PRM F
9 Clerks-DMP DMP PRM F
Clerks-Wards Wards PRM F
10 Patient NA PRM I
For Internal Use Page 196 of 232
MedMantra Software Requirements Specifications ver.0.1
F – Full Access (Read / Create / Update / Delete)
I – Insert (Insert / Write Access_
R – Read (Read)
U – Update (Update)
D – Delete (Delete)
3.18 Assumptions and Dependancies
Assumptions
Sms & E-mail integration are part of the module
Dependencies
Involvement of the end users in signing off this SRS document. Availability of installed hardware/System software for implementation.
3.19 Interface / Integration Needs
a. External Application Interfaces
Sr. No.
Interface Name
Description Direction Triggering Mechanism
Source System
Target System
1 AHC to Wellness
Wellness Software
Wellness Software
PRM
2 EMR to Disease Management Program
Disease Management Program Software Integration
DMP software
PRM
3 EDOC to Appointment follow up
E Doc software integration
E-DOC PRM
4 Apollo website integration
Information, Enquiry request, Information requests, feedbacks from th e website needs to be integrated
Apollo website
PRM
5 Doc Connect Referral from referral doctor
Doc connect PRM
For Internal Use Page 197 of 232
MedMantra Software Requirements Specifications ver.0.1
software
6 SMS Module Integrated with PRM
7 E-mail Integration
Outlook or any standard e-mail platform
PRM
b. Equipment/Device Interfaces
Sr. No.
Equipment Name
Description Make Model Department Direction Triggering Mechanism
1 Remote health monitor
Monitors vitals & key parameters of the patient
Based on Algorithm
2
3
4
5
6
7
3.20 Performance Requirements -NA-
3.21 Logical Database Requirements -NA-
3.22 Design Constraints -NA-
For Internal Use Page 198 of 232