This conceptual design of the Medical Data Management Software product had to be the following:
It had to be the go-to resource for clients.
It had to be built on a stable platform to include future expansion.
It had to provide secure data transfer and storage.
It had to provide a HIPAA-compliant exchange of information.
It had to be a high-performance software product.
It had to be simple and easy-to-use.
It had to be fully documented.
It had to beat the market competition with superior functionalities.
Detailed Features List
We divided the requirements into the following modules:
User’s management – This is one of the most important aspects of any information portal. Multiple layers of security were incorporated, and strict roles were defined.
We assigned different roles of users based on their permission to access the various sections of the application.
Users were defined as administrators, technicians, or support staff. The user was allowed to decide and customize the information he/she wanted to display.
An administrator (i.e. administrator of the MED DataLink clients) was given privileges to change and define the levels of permission to different sections of the application for other users.
Records Management – Each company had its own patient and appointment related information. Every record had different types of dynamically generated data elements.
Users could dynamically create the text box, text area, checkbox, radio button, dropdown, and store the records in the system.
Notifications Management – Whenever a new patient’s appointment record was created or an existing patient’s information was updated, then a notification was triggered to the users (based on their notification permission).
These notifications were sent via email with the user’s home page screen. Users could enable/disable the notifications sent to them based on different actions performed in the application.
Business Partner Management – The client had multiple dynamically generated business partners.
Each business partner has his own company information, his users along with the current, past and future contracts.
Contract Management – Each contract of a business partner had additional fees like data storage fee, last payment overdue fees, etc.
Every service had its own defined fee. Every contract had a start and end date along with its trial period.
Places of Service Management – Each patient record had a place of service. The place of service had its name, address, and other information.
All business partner could create/edit their own places of service and every place of service has multiple associations of users.
Financial Data Management – It includes the invoicing to the business partner. There were two types of invoices:
Create an invoice for each business partner by selecting the records of that business partner and applying the service, additional fee etc.
Create an automatic invoice to each business partner at a specified date in a month. The client can define the different dates for each business partner to create this automatic invoice.
Adjustment on Invoices – A client can apply the adjustment to any invoice. An adjustment can be made on the pre-generated invoice or it can be applied in the future generated invoice.
Payment on Invoice – Payments on invoices are done through credit cards via the authorized .net payment gateway. If a user pays an extra amount with an invoice, then an auto adjustment is created for the balance amount that is deducted from the future invoice of that business partner.
Invoice due Notification – If a business partner (MED DataLink’s partner) did not pay the invoice within the due date, then after 30, 60 or some defined days, an email notification would be sent to the business partner.
Data Element Management – A client can create dynamic data elements like text box, text area, radio button, file data element, date type data element, or form data element.
Data element form has different types of its own data element like text boxes, text area, radio button, or inherited data element.
We created different sets of permission on the data element i.e. the accessing of data elements via the different role users.
File Management on Server through Rack Space – A client can directly manage/upload/download through the Rack Space API instead of moving the file to a server and then to Rack Space.
Physician Report Generator – The software product was given the functionality of report generation through the LaTex PDF creation software with the Smarty templates.
For instance, a physician generates a comprehensive report. The report would have various sections and contain all-important records.
Our project manager, solutions architects, and sr. programmers reviewed and analyzed the documents received from the client.
Team BluEnt reviewed the existing technology platforms and recommended LAMP technology stack to increase the scalability and robustness of the existing web platform.
We had several rounds of discussions with the client and scheduled weekly meetings to understand the objectives, finalize the requirements and decide the delivery approach.
Design and Development Phase – The software project was divided into phase-in plans where the clients slowly introduced a small percentage of their clients to the software in order to receive feedback, make user experience improvements, and defect fixes before migrating all users and their data to the new software.
We developed the cloud-based application which could run on multiple servers in separate cites.
Data Migration Process – BluEnt developed a secured and reliable data migration plan to move existing customers and their data to the new software.
We had developed a reverse-migration plan in case of any unexpected errors.
Quality Assurance (QA) Plan – BluEnt developed a quality assurance plan to test for software defects.
BluEnt developed and distributed this QA plan to all team members and set their QA responsibilities and overall schedule.
Users Manual Development – BluEnt developed comprehensive documentation of the code and platform used to build the software application.
The step-by-step instructions were listed in the “Application Developer Guide”. Each step was explained explicitly in the corresponding section of the template.
CakePHP, Smarty, LaTex for PDF creation
The application was required to run on multiple servers located in separate sites.
This setup had to be fault tolerant, for instance, if a server or an entire city becomes unreachable or partially reachable, the system had to be able to keep the application online for some defined ratio of the user base (or the entire user base, if possible).
It had to be able to reunite with the failed system, all without manual intervention.