Introduction
This project aims to get a functional Voice/SMS server in production. The idea is to deploy and enhance the ‘Raxa_Voice_SMS’ module (one of last year’s GSoC project) to support patient follow ups. The system will call up or SMS patients to ask for their health parameters (such as blood pressure). The followup frequency can be set by the doctors (daily, weekly etc.) These followups will be communicated to the system using the OpenMRS REST API.
Project Features
Asterisk based follow-up through call.
SMS based message follow-up.
Automatic Speech Recognition (ASR) for calls implementation.
Local language translation on calls.
Option for patients to record conversations with doctors and later playback.
Doctor UI for creating and viewing followup information.
Voice messaging.
Appointment scheduling system via call.
Timeline
May 19 - June 5
Start work on the ‘Call based system’. Create UML diagrams and mockups as required. Create a fully functional ‘FollowUpCallHandler’ class. Move current call handler to ‘ReminderCallHandler’ class. Extract generic features to ‘CallHandler’ base class. Create ‘FollowUpResponse’ table as well as corresponding Hibernate classes.
June 5 - June 15
Add option to deal with patients who haven’t registered on the called number. Write method which will request their primary mobile number and add the presently called one as secondary number. Modify Scheduler class and add new queries to the REST call properties file. At the openMRS end, create a new encounter_type for call/sms followups.
June 16 - June 26
Write code for SMS based followup system. This would require generalizing existing code in the AlertMessage module to serve alerts as well as followups. Classes like FollowUpInformation, FollowUpTemplate, FollowUpContentFormatSMS needs to be implemented.
Re factor code. Submit for code review. Document all modifications.
June 26 - July 6
Implement speech recognition using the Google Speech engine. Integrate it with current ‘Raxa_Voice_SMS’ module. This might not be possible for all local languages. So initially check whether user’s preferred language is the supported. If not, resort to IVR based menus and keypad inputs. If it is supported, use voice inputs to get user inputs. This can be implemented for both the followups as well as reminder call work flows.
Current methods like getOptionFromTTS() which returns user choice can be modified to decide between keypad input and voice input based on language support. In this way, existing code modifications can be minimised.
In case of followup, the confidence levels of options listed needs to be calculated. In case, they fall below a threshold i.e. cannot be sufficiently distinguished and recognized, we need to go for keypad based input. This can be calculated at the form creation time itself and possibly entered as an attribute in the database table.
July 6 - July 15
Make the voice-server live with the following features: Call based followup and automatic speech recognition. Research will be done to identify best option among Indian voice server hosting companies.
Installing required plugins Taking the code to production would involve replacing all SIP related connections & dial plan settings to actual DAHDI based settings among other minor changes.
July 16 - July 26
Implement the appointment scheduling module using voice/SMS. This would require creating new classes such as the AppointmentSchedulingCallHandler. The system should connect to OpenMRS webservices using REST APIs during the call to get the available time slots based on user input. When the patient chooses a slot, this needs to be updated in the system as well.
Reminders should be send on predefined intervals before appointment. An option for a patient who have booked an appointment to cancel the same (in case he/she won't be able to make it) will also be implemented.
July 27 - August 7
Write code for voice messages and call recording. This can be implemented as two methods in base CallHandler class since the behavior would be the same in all cases. Code will also be written to keep track of stored messages and remove expired ones.
Re-factor code. Document all modifications. Submit for code review.
August 8 - August 18
Move the remaining features of the service into production.
The two weeks time is given to account for any unexpected delay or problems that we might face while taking the server live (with Murphy’s law in mind).