Patient Relationship Management

293
MedMantra Software Requirements Specifications ver.0.1 Med Mantra Patient Relationship Management Software Requirements Specifications Version 0.3 Internal Use Only i

description

Patient Relationship Management

Transcript of Patient Relationship Management

Page 1: Patient Relationship Management

MedMantra Software Requirements Specifications ver.0.1

Med Mantra

Patient Relationship ManagementSoftware Requirements Specifications

Version 0.3

July 20, 2013

Internal Use Only i

Page 2: Patient Relationship Management

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

Page 3: Patient Relationship Management

MedMantra Software Requirements Specifications ver.0.1

Internal Use Only iii

Page 4: Patient Relationship Management

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

Page 5: Patient Relationship Management

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

Page 6: Patient Relationship Management

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

Page 7: Patient Relationship Management

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

Page 8: Patient Relationship Management

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

Page 9: Patient Relationship Management

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

Page 10: Patient Relationship Management

MedMantra Software Requirements Specifications ver.0.1

2.2 Interrelation of Modules

Internal Use Only 4

Page 11: Patient Relationship Management

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

Page 12: Patient Relationship Management

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

Page 13: Patient Relationship Management

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

Page 14: Patient Relationship Management

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

Page 15: Patient Relationship Management

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

Page 16: Patient Relationship Management

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

Page 17: Patient Relationship Management

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

Page 18: Patient Relationship Management

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

Page 19: Patient Relationship Management

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

Page 20: Patient Relationship Management

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

Page 21: Patient Relationship Management

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

Page 22: Patient Relationship Management

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

Page 23: Patient Relationship Management

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

Page 24: Patient Relationship Management

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

Page 25: Patient Relationship Management

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

Page 26: Patient Relationship Management

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

Page 27: Patient Relationship Management

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

Page 28: Patient Relationship Management

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

Page 29: Patient Relationship Management

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

Page 30: Patient Relationship Management

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

Page 31: Patient Relationship Management

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

Page 32: Patient Relationship Management

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

Page 33: Patient Relationship Management

MedMantra Software Requirements Specifications ver.0.1

sometime

Remarks Remarks if any C Varchar 200      

Internal Use Only 27

Page 34: Patient Relationship Management

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

Page 35: Patient Relationship Management

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

Page 36: Patient Relationship Management

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

Page 37: Patient Relationship Management

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

Page 38: Patient Relationship Management

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

Page 39: Patient Relationship Management

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

Page 40: Patient Relationship Management

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

Page 41: Patient Relationship Management

MedMantra Software Requirements Specifications ver.0.1

Address Patients Address

If preferred mode of contact is snail

mail

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

mail

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

Page 42: Patient Relationship Management

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

Page 43: Patient Relationship Management

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

Page 44: Patient Relationship Management

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

Page 45: Patient Relationship Management

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

Page 46: Patient Relationship Management

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

Page 47: Patient Relationship Management

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

Page 48: Patient Relationship Management

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

Page 49: Patient Relationship Management

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

Page 50: Patient Relationship Management

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

Page 51: Patient Relationship Management

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

mail

  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

Page 52: Patient Relationship Management

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

Page 53: Patient Relationship Management

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

Page 54: Patient Relationship Management

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

Page 55: Patient Relationship Management

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

Page 56: Patient Relationship Management

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

Page 57: Patient Relationship Management

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

mail

  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

mail

  T Q    

Ref. Dr. Contact

Referral Doctor contact number C Numb

er 50   If preferr   T Q    

For Internal Use Page 24 of 232

Page 58: Patient Relationship Management

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

Page 59: Patient Relationship Management

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

Page 60: Patient Relationship Management

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

Page 61: Patient Relationship Management

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

Page 62: Patient Relationship Management

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

Page 63: Patient Relationship Management

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

Page 64: Patient Relationship Management

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

Page 65: Patient Relationship Management

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

Page 66: Patient Relationship Management

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

Page 67: Patient Relationship Management

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

Page 68: Patient Relationship Management

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

Page 69: Patient Relationship Management

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

Page 70: Patient Relationship Management

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

Page 71: Patient Relationship Management

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

Page 72: Patient Relationship Management

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

Page 73: Patient Relationship Management

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

Page 74: Patient Relationship Management

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

Page 75: Patient Relationship Management

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

Page 76: Patient Relationship Management

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

Page 77: Patient Relationship Management

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

Page 78: Patient Relationship Management

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

Page 79: Patient Relationship Management

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

Page 80: Patient Relationship Management

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

Page 81: Patient Relationship Management

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

Page 82: Patient Relationship Management

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

Page 83: Patient Relationship Management

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

Page 84: Patient Relationship Management

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

Page 85: Patient Relationship Management

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

Page 86: Patient Relationship Management

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

Page 87: Patient Relationship Management

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

Page 88: Patient Relationship Management

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

Page 89: Patient Relationship Management

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

Page 90: Patient Relationship Management

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

Page 91: Patient Relationship Management

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

Page 92: Patient Relationship Management

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

Page 93: Patient Relationship Management

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

Page 94: Patient Relationship Management

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

Page 95: Patient Relationship Management

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

Page 96: Patient Relationship Management

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

Page 97: Patient Relationship Management

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

Page 98: Patient Relationship Management

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

Page 99: Patient Relationship Management

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

Page 100: Patient Relationship Management

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

Page 101: Patient Relationship Management

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

Page 102: Patient Relationship Management

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

Page 103: Patient Relationship Management

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

Page 104: Patient Relationship Management

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

Page 105: Patient Relationship Management

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

Page 106: Patient Relationship Management

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

Page 107: Patient Relationship Management

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

Page 108: Patient Relationship Management

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

Page 109: Patient Relationship Management

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

Page 110: Patient Relationship Management

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

Page 111: Patient Relationship Management

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

Page 112: Patient Relationship Management

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

Page 113: Patient Relationship Management

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

Page 114: Patient Relationship Management

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

Page 115: Patient Relationship Management

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

Page 116: Patient Relationship Management

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

Page 117: Patient Relationship Management

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

Page 118: Patient Relationship Management

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

Page 119: Patient Relationship Management

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

Page 120: Patient Relationship Management

MedMantra Software Requirements Specifications ver.0.1

Figure : Counseling of Patients/Attendants

For Internal Use Page 87 of 232

Page 121: Patient Relationship Management

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

Page 122: Patient Relationship Management

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

Page 123: Patient Relationship Management

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

Page 124: Patient Relationship Management

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

Page 125: Patient Relationship Management

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

Page 126: Patient Relationship Management

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

Page 127: Patient Relationship Management

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

Page 128: Patient Relationship Management

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

Page 129: Patient Relationship Management

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

Page 130: Patient Relationship Management

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

Page 131: Patient Relationship Management

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

Page 132: Patient Relationship Management

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

Page 133: Patient Relationship Management

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

Page 134: Patient Relationship Management

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

Page 135: Patient Relationship Management

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

Page 136: Patient Relationship Management

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

Page 137: Patient Relationship Management

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

Page 138: Patient Relationship Management

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

Page 139: Patient Relationship Management

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

Page 140: Patient Relationship Management

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

Page 141: Patient Relationship Management

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

Page 142: Patient Relationship Management

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

Page 143: Patient Relationship Management

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

Page 144: Patient Relationship Management

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

Page 145: Patient Relationship Management

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

Page 146: Patient Relationship Management

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

Page 147: Patient Relationship Management

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

Page 148: Patient Relationship Management

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

Page 149: Patient Relationship Management

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

Page 150: Patient Relationship Management

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

Page 151: Patient Relationship Management

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

Page 152: Patient Relationship Management

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

Page 153: Patient Relationship Management

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

Page 154: Patient Relationship Management

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

Page 155: Patient Relationship Management

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

Page 156: Patient Relationship Management

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

Page 157: Patient Relationship Management

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

Page 158: Patient Relationship Management

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

Page 159: Patient Relationship Management

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

Page 160: Patient Relationship Management

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

Page 161: Patient Relationship Management

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

Page 162: Patient Relationship Management

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

Page 163: Patient Relationship Management

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

Page 164: Patient Relationship Management

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

Page 165: Patient Relationship Management

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

Page 166: Patient Relationship Management

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

Page 167: Patient Relationship Management

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

Page 168: Patient Relationship Management

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

Page 169: Patient Relationship Management

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

Page 170: Patient Relationship Management

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

Page 171: Patient Relationship Management

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

Page 172: Patient Relationship Management

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

Page 173: Patient Relationship Management

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

Page 174: Patient Relationship Management

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

Page 175: Patient Relationship Management

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

Page 176: Patient Relationship Management

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

Page 177: Patient Relationship Management

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

Page 178: Patient Relationship Management

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

Page 179: Patient Relationship Management

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

Page 180: Patient Relationship Management

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

Page 181: Patient Relationship Management

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

Page 182: Patient Relationship Management

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

Page 183: Patient Relationship Management

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

Page 184: Patient Relationship Management

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

Page 185: Patient Relationship Management

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

Page 186: Patient Relationship Management

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

Page 187: Patient Relationship Management

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

Page 188: Patient Relationship Management

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

Page 189: Patient Relationship Management

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

Page 190: Patient Relationship Management

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

Page 191: Patient Relationship Management

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

Page 192: Patient Relationship Management

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

Page 193: Patient Relationship Management

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

Page 194: Patient Relationship Management

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

Page 195: Patient Relationship Management

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

Page 196: Patient Relationship Management

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

Page 197: Patient Relationship Management

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

Page 198: Patient Relationship Management

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

Page 199: Patient Relationship Management

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

Page 200: Patient Relationship Management

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

Page 201: Patient Relationship Management

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

Page 202: Patient Relationship Management

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

Page 203: Patient Relationship Management

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

Page 204: Patient Relationship Management

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

Page 205: Patient Relationship Management

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

Page 206: Patient Relationship Management

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

Page 207: Patient Relationship Management

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

Page 208: Patient Relationship Management

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

Page 209: Patient Relationship Management

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

Page 210: Patient Relationship Management

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

Page 211: Patient Relationship Management

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

Page 212: Patient Relationship Management

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

Page 213: Patient Relationship Management

MedMantra Software Requirements Specifications ver.0.1

3.16.4 Request form

For Internal Use Page 180 of 232

Page 214: Patient Relationship Management

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

Page 215: Patient Relationship Management

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

Page 216: Patient Relationship Management

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

Page 217: Patient Relationship Management

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

Page 218: Patient Relationship Management

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

Page 219: Patient Relationship Management

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

Page 220: Patient Relationship Management

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

Page 221: Patient Relationship Management

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

Page 222: Patient Relationship Management

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

Page 223: Patient Relationship Management

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

Page 224: Patient Relationship Management

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

Page 225: Patient Relationship Management

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

Page 226: Patient Relationship Management

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

Page 227: Patient Relationship Management

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

Page 228: Patient Relationship Management

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

Page 229: Patient Relationship Management

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

Page 230: Patient Relationship Management

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

Page 231: Patient Relationship Management

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