Visiting Physician Bid Proposal Decision

Team Leader: Adam Johnson

Team Members:

Eman Alawani Salma Almotlaq Chanese Charlton Corey Mee

Doug Ramundo Sandy Weng William Yang Michelle Ziogas

Background & Introduction

Visiting Physician, founded in October 2015, is a biomedical software engineering firm that dedicates itself to creating a suite of products that mine and process all currently available medical information in order to provide patients, healthcare professionals, and insurance providers the most up-to-date information on all aspects of healthcare.

The expert systems that Visiting Physician develops uses natural language processing, an inference engine, a massive database, and special purpose search engines to provide a variety of services, specifically for our flagship products, including our medical search engine and insurance claims processing application. The medical search engine will provide users with the ability to more easily search the web for the most up-to-date information about medical conditions, pharmaceuticals, and other relevant medical information. Also, Visiting Physician is currently developing an insurance claims processing application that will allow users to upload insurance claims, receipts, and other relevant documentation to their claims adjuster and to see the status of claim in real time. Visiting Physician promises 100% up-time for all users anywhere in the world and they ensure that all modules will be fully accessible by people with disabilities.

This report is a summary of the factors we found to be essential in evaluating project bids and an elaboration on how it influenced our decision. We conclude with our final proposal decision referencing details related to the proposals submitted by Achievers, LLC, Foresight Coordinated Technologies, and HealthcAIR Solutions.

Functional RequirementsIn regards to the functional requirements, like we had mentioned in our meetings

and questions responses, we had a minimum list of functional requirements that we would like for our contractor to take into consideration (The list is also provided below):

• Natural language processing

• Inference engine

• Massive database

• Special purpose search engine

• Ability to provide patient advice for a variety of conditions

• Ability to provide caregivers with advice

• Ability to assist with processing insurance, Medicare and disability claims

• Ability to provide diet and exercise advice

• Ability to provide advice and information on all types of medication and dietary supplements

• Ability to provide advice and instructions on using a wide variety of medical equipment

• Simple user-interface (must be user-friendly)

Thus, we scored the groups based upon how much of the functional requirements they took into consideration and how they were going to achieve those requirements.

Non-Functional Requirements

The non-functional requirements should be implemented into the system to ensure that the user would have a good experience while interacting with the system. Based on the Visiting Physician team member’s specifications for the system, these are the non-functional requirements for the Visiting Physician system:

• Security

o Login/ Password requirements – There should be different access privilege levels

for different types of users. Also, the password should be case sensitive and contains a combination of letters, numbers, and special characters. The length of the password should be limited and the user should change it every 90 days. o Inactivity timeouts –

The user should be able to set the duration of time when the

system should log out automatically once the user is no longer active. o The software must meet Federal and HIPAA regulations

• Compatibility

The system should be compatible with different platforms and operating systems. Multiple mobile applications will be developed; one for each individual module and the website should be mobile-friendly.

• Performance

The response and processing time should be between 3-5 seconds.

• Integrity

The system should be integrated with other systems such as insurance companies, payment authorization parties and health services providers. By integrating with these systems’ databases, we will be able to ensure that the information our system contains is valid/correct.

• Capacity

o We would want to use an off-site data center for the following objects: o We would be housing large amounts of data we collect from online resources as

well as data on all of our customers and patients. o For scalability concerns (so that we don’t have to worry about purchasing

additional/new servers as we expand). o For the fact that the data demands may not be consistent (i.e. during certain

periods of time, there can be heavier demands on the servers or less).

• Availability

Visiting Physician’s system should be available for all of its users at all times.

• Reliability

The system should be able to perform its functionality without any failure. If a failure is experienced, the system should have a backup copy of the user’s latest activities.

• Usability

o The system should be user-friendly. o It should support multiple languages (English for the first version). o Use natural language processing. o The system should be standardized in regard to signs, keyboard shortcuts, and UI

metaphors

• Documentation

The system should have a help function provided, which contains documentation for the various modules and their functionality that we support.

MethodologyIn selecting the right project management approach our instinct was to lean

towards the contractors to choose best methodology that their team is most comfortable with. We have this great idea and a company that understands our needs was very important.With the expectation that there will be multiple deliverables we expect the process chosen to be iterative where the team can prioritize features and allow us to provide user feedback .With so many different – and in some cases, overlapping – approaches to managing the complexities of any given project, Visiting Physician is expecting the contractor to keep us involved in all aspects from inception to the final launch. We expect them to have full knowledge of the process they choose and have experience working this method on multiple projects. We also are looking for some detail when it comes to the high level plan and the flow/order in which things will go

Project Timeline & ScheduleWhen we were evaluating the bid proposals for their project timeline and

schedule, there were a few points that we focused on and wanted to see. We were looking for a detailed timeline, which included the estimated delivery date and the development time needed for each module or portion of the project. This was very important for our decision-making process as it allows for us to determine if the proposal is feasible, and also allows us to plan the other aspects of the project (marketing and sales activities, legal filings, trademarks, etc.). The timeline should reflect that for the first phase, we want the initial beta module launched at 9 months and a full release at 12 months. We would like the second module released 6 months after the full release. Lastly, every six months afterwards, we would like to have an additional module released, until we’ve released the full set of modules for Visiting Physician.

Development Team Breakdown

When it came to the contractor group’s development team, we wanted to understand what personnel resources were allocated to each part of the project. Specifically, we wanted to know how many people would be involved in each phase of the project, broken down by their job roles and preferably by expertise. We were also evaluating whether the resources allocated seemed realistic.

Budget EstimateThere are two important factors we consider when looking at the budget

estimate. First is that the budget is realistic to the scale of our project. We believe that any estimate that falls far below or greatly exceeds our anticipated budget is a sign that we don’t share the same vision for this program. At this point in the proposal process, it should be clear that Visiting Physician is an immense project and the estimate should be reflective of that.

Second, we want the details within the budget to offer insight of expected costs to be sure that each team has anticipated the needs of the project and better ensuring that they won’t go over budget for things they hadn’t planned for. We believe that items like training, testing, and documentation are essential funds that will attribute to a more successful project in the long-term

Formatting & ProfessionalismThe formatting of the bid proposal is the first impression each team is offering of

their work, therefore places some importance of its appearance. The presentation of the bid a testament toward their professionalism, showing us how they perceive the potential in being chosen for this project. We see a strong presentation as a desire to work with us and show us an example of the potential that they can offer to the appearance of Visiting Physician.

pros: the good parts of the proposal is that they colored very easy to identify, very clear letter format perfect professional, titles are very clear and easy to read sort the idea, especially the form. time, date, and company name,bullet point.

cons: single color/ take more time to read. cover letter. schedule and budget. need more resume concept, anything that takes extra effort. the format reflects how well you can do the job.

SecuritySecurity is our top priority since our system will have sensitive information such

as patients’ medical records and payment information. Therefore, in Visiting Physician we are seeking a highly secure system in order to gain our users’ trust and keep their information confidential. So, we expected the contractors to provide thorough details about security and how it will be consistent with our functional and non-functional

requirements. Also, how the security aspects, such as integrity, privacy, non-repudiation, authentication, and authorization, would be addressed. Additionally, we wanted to see how the system would respond to any security threat and how the data would be safely transmitted over the network.

Final Product Deliverables

The Visiting Physician team not only expected details regarding functional and non- functional requirements, but also required that contractors tie all of this information into a list of final product deliverables. Together, these deliverables indicate to us what the component parts of any product will result in; that is, a convincing case of what the product will actually do once all of the pieces are in place. It is not enough to say that the product will include an easy-to-use natural language interface, if the contractor is not able to say how this interface will translate into a useful and practical product. A strong list of deliverables, moreover, is a good indicator that a team has worked on a project of this magnitude before and can contribute a vision for the product. Ultimately, as a partner in the Visiting Physician product, the contractor must share a holistic vision for the user experience. Key deliverables that we expect are a description of how modules would interact across phases, training and documentation for specific releases, and database access levels following data conversion efforts.

Timely SubmissionWe had communicated with each of the contractor teams that the bid proposal

submission deadline was Sunday, November 22, 2015 at 12:00 p.m. Timely submission of the bid was considered as an indication of how well each team could deliver to a deadline. As such, we decided that it was reasonable to assess a penalty in the final scoring rubric for late submissions. It was decided that a 5 point penalty would be applied for any late submissions up to 12 hours, and any submissions after that time would not be considered due to the fact that the review process was already underway.

Bid DecisionThe Visiting Physician team views our selected contractor as a partner in this

project, not just a paid outside stakeholder. As such, we ask that they present a clear and comprehensive plan for how the project will be completed. This includes a detailed list of functional and non- functional requirements, a breakdown of the methodology that will be used, and precise and realistic figures regarding schedule, staff and budget. Moreover, because our system will handle large amounts of sensitive patient information, we require a thorough explanation of how customer security will be guaranteed. All three responding contractors addressed these issues with varying degrees of success; below is our rationale for selection, along with stipulations for signing a contract with the qualifying contractor.

As previously mentioned, system security constitutes the most important functional and non-functional requirement for Visiting Physician. If a contractor presents an outstanding project plan that is lacking in an adequate security component, Visiting Physician will not be able to assume the potential for legal liability and damage to brand image, until these concerns are addressed. HealthcAIR Solutions provided the clearest and most complete information regarding how system security will be achieved. Both Achievers, LLC and Foresight Coordinated Technologies fell very short of the mark in

this regard, providing scant details about how patient information will be protected. Prior to signing a contract, the Visiting Physician team requires

that the selected vendor provide an appendix dedicated to system security, outlining

how federal, state, local and industry standards (chiefly, HIPAA) will be maintained.

Regarding additional functional and non-functional requirements, most of the contractors did an at least fair job in communicating the component parts that will make Visiting Physician a success. Achievers, LLC did a fantastic job of outlining functions for end users, system administrators and outside stakeholders in all of the project phases. In particular, they focused on the components of user-friendliness and client satisfaction – such as continuous improvement, adaptability and help/documentation – which indicate that the Achievers team fits well into the aforementioned role of a project partner. HealthcAIR Solutions also provided a detailed list of requirements and, in addition, helped the Visiting Physician team to anticipate possible problem areas by including design constraints. Foresight Coordinated Technologies disappointed in this area by not explicitly listing requirements for the system, leaving us to wonder how they will address key areas including compatibility, integrity, availability and usability.

As the Visiting Physician team will be trusting much of the project stewardship to our selected contractor, it is crucial that they provide a strong case for the methodology that they select. While we prefer an agile methodology (in keeping with current industry best practices) we are willing to consider alternatives if a good rationale is provided. Once again, Achievers, LLC impressed us by matching our expectation and demonstrating a longstanding commitment to using an agile methodology. Foresight Coordinated Technologies took this a step further and provided a breakdown for the implementation of SCRUM, which would be particularly beneficial once post-launch project reviews are initiated with the Visiting Physician team. Lastly, HealthcAIR Solutions disappointed in this area, as they did not provide a suggested methodology, which indicates a lack of crucial project process ownership.

In addition to the largely qualitative indicators listed above, the Visiting Physician team also looked closely over figures for schedule, staff and budget. Foresight Coordinated Technologies did a fantastic job of providing a month-by-month breakdown of completed tasks. Additionally, they aligned these completion dates with the respective employees, all within the SCRUM framework. Achievers LLC provided a sufficient plan for staff allocations and scheduling, but fell short on providing details on key milestones and project players. This is somewhat acceptable, given their use of agile methodology, but we would like to see a more detailed breakdown. HealthcAIR Solutions took an uneven approach to schedule and staffing, by providing detailed numbers for staff commitments in each phase but not giving more details on which staff are to be involved and what dates tasks and modules will be completed by. This, combined with their large team of developers and analysts, raises concerns regarding project ownership or accountability by their staff.

Finally, budget is of great concern to Visiting Physician. We are looking for realistic numbers and believe that we can judge a fair offer based on our years of

experience in this industry. We have serious doubts about HealthcAIR Solutions’ ability to deliver a quality product for under a million dollars, and their quote leads us to have reservations regarding their experience in working on a project at this level. Considering that the standard industry rate for hiring ten developers and analysts for one year would equal or exceed their quoted total for the

entire project, we do not find this amount to be suitable. Foresight Coordinated

Technologies came closer to the mark and, given an aggressive schedule and factoring in future change orders, these numbers could be fairly realistic. Their proposal to discount the total by using existing technologies presented a great option for consideration. Finally, Achievers, LLC provided a very realistic estimate. Their consideration of the costs associated with completing a project of this magnitude makes us confident that they are serious about making Visiting Physician a priority for their company.

Ultimately, while all teams displayed strengths and weaknesses, we believe that Achievers, LLC would be the best partner for the Visiting Physician project. Their strengths in outlining requirements, choosing an agile methodology and providing realistic financial estimates outweighed some of their weaker areas. Despite this, we require that a detailed list of requirements for system security be appended to their proposal before moving forward. Before a contract is signed, we must have confidence that their product will meet local, state, federal and industry requirements for patient security. We understand that these additions may factor into the overall cost and we are prepared to receive an update budget upon completion of the appendix. We hope that this arrangement works well for Achievers, LLC and look forward to our partnership on this project.

Scoring MatrixProvided on the next page is the scoring matrix containing the score breakdown of each of the contractor bids we received. A more detailed version of this information can be found in Appendix A (The excel spreadsheet attachment).

Criteria ScoredAchievers, LLC

Foresight Coordinated TechnologiesHealthcAIR Solutions

Background/Introduction 9.83 8.83 6.67

Functional Requirements 8.50 3.67 8.00

Non-Functional Requirements 8.17 3.67 8.50

Methodology 8.67 10.00 1.67

Project Timeline/Schedule 6.00 9.83 3.50

Staff Breakdown 6.50 8.83 6.67

Budget Estimates 8.50 9.00 5.67

Formatting/Professionalism 9.67 6.33 6.50

Security 2.50 0.83 8.50

Final Product Deliverables 9.50 7.33 6.83

Timely Submission 10.00 10.00 5.00

Total Points 87.84 78.32 67.51