Creating a location-based web application for medical tourism

Prologue

In today’s post, I’ve presented a case study for a medical tourism patient app that was requested by an established client of several years who is a medical travel facilitator in business for nearly 10 years. The client has an established brand that specializes in a microniche service for medical travelers to destinations in 6 countries. The firm coordinates the episode of care and travel arrangements for approximately 250 clients per year.

In September 2018, the medical tourism facilitator firm experienced its worst sales decline in over a decade. After deep analysis, its CEO decided that a better way to distinguish its brand from other facilitator firms would be to increase client engagement through a location-based web application to enable clients to check in at various locations at the treatment destination and again back home. To enhance the value proposition of their service and program, they also wanted to:

• offer exclusive client-oriented sponsored coupons and promotions through the app if they were close to a restaurant, gift shop, pharmacy, or other tourism, hospitality, retail, attraction or ancillary partner at the destination;
• offer real-time security enhancement to the clients in the event a high-risk situation arose that could jeopardize the client’s safety (bad weather, civil disturbance, natural disaster, etc.) The app would send notices to the user in real time if notifications were allowed by the user upon installation.
• send appointment and activity reminder notices, including medication dosing reminders
• provide location specific directions and send notices to providers if the client would arrive late for a scheduled appointment, and would also calculate an estimated time of arrival under current conditions.
• To monitor aftercare, clients could continue to use the app upon return back home to record test results, pain management details, continued patient-perceived clinical improvement, and to request medical records transfers from provider-to-provider. This would allow the facilitator to maintain a relationship with clients long after the medical travel has concluded.

The facilitator has a modest development budget and desires to run a pilot to better understand whether location-based offers will increase brand value, loyalty and attract more clients.

The client assignment and scope of work

Our assignment was to:

1. Create an app that will prove whether location-based offers are effective.
2. Limit the app to work on just one medical travel destination of our client’s choosing to be tested over a period of 180 days.
3. Obtain permission to know and monitor the location of customers using the app.
4. Show offers and reminder notifications to those customers throughout their journey and upon return home.

Terms and conditions of the pilot development and intellectual property rights

The facilitator currently has a website. If this pilot is successful, the facilitator will incorporate the app into its business and make available both an Apple and Android mobile app as a client amenity. The facilitator has also requested to pay the developer for exclusive rights to use the app for a period of 36 months before the app can be offered to the developer’s other clients. The parties have agreed that the developer will register the patent on the app and white label the app for use by the facilitator for the three year exclusive use license. Ownership of the technology will remain with the developer because the work for hire price was more than the facilitator could afford to pay.

Developer preliminaries and process

The developer and client have agreed on the transactional terms but a great deal of additional information will be required before development can begin. Among others, the programmer will need to know the following:

1. What will the app look like?
2. What programming languages will be needed to create the app?
3. How will the programmer write code to locate a user’s present location?
4. What offers will be shown to a user who has agreed to share their information through the app?

To obtain answers to these and other questions in an organized way, a standard development process should be followed.

Pricing and timeline

Building an app can take as little time as an hour or as long as decades. A typical development process for the initial app prototype averages one or two months to complete, whereas enterprise development processes for commercial grade software take six months to a few years to complete, depending on the industry and the project’s complexity. Unfamiliar with computer programming, the facilitator was concerned that the cost to develop and test the app would be prohibitive and take a longer time than anticipated. To reassure the facilitator that the prototype would be completed as soon as possible, the programmer prepared a brief overview of the entire process, and then elaborated additional steps as they proceeded to build the app for the client.

The four milestone steps to build the app include:

1. Planning and discovery of app requirements (30% of time)
2. Researching of technology needed to build the app, and designing the app’s look and feel (30% of time)
3. Coding your app using a programming language (10% of time)
4. Debugging and testing your code when it behaves differently than you intended (30% of time)

If the programmer charged only for time to build and test the app, a small invoice of 2-5 hours time would be billed. Planning and research alone would consumer 2-3 hours. The value in this app was more heavily weighted in the patent registration and the exclusive use licensing agreement. The remainder of the time would be spent debugging the code to correct syntax and logic errors. The app could be tested in the facilitator’s home city just as it could any other location. In order to set a price to build and test the app, the developer would need to have its own capital to pay the legal and filing costs to register and execute the patent, and the legal costs to develop the licensing agreement. The developer must also provide the seed capital to undertake development (including overheads, tools, and equipment, code authors, business operating expenses and profit margin) without advance payment from the facilitator. Payment for five hours of development time would barely cover the cost to pay the team to write the code.

Many clients approach programmers with web app ideas day in and day out. The planning phase is the time when we put ideas down on paper. Documenting all the features that will go into the app is so important. For both parties, until there is a true meeting of the minds, it can be difficult if not impossible to understand which features are technically easy versus challenging to produce and test. For the facilitator to monetize the app, it will need to provide value and be easy to use by end users, and an incremental direct cost to provide the app and host operations on a secure, encrypted, per user basis must be bundled into the base cost for the facilitator’s package of professional services to be rendered and collected up front whether the customer decides to use the app or not.

The planning phase also facilitates an up-front conversation around time, project scope, and budget, where a common saying is to “pick two out of the three.” In projects for small operators, resources are always scarce, so it’s more common to adjust the project scope or extend the timeline than to increase the project’s budget. Before writing any code, it will be helpful to understand which dimensions can be flexed and which are fixed. Utilization will correlate to server use. At the present rate of new client growth and utilization, the facilitator coordinates care for approximately 1500 clients per year. Assuming a 60% utilization among clients, the server needs for a three-year exclusive licensing agreement would be 3500-4500 users plus room to grow, and while the facilitator currently refers patients to 26 countries, within those 26 countries geolocation and business development for the coupons and partner offers could expand over time to include more than once city per country plus the geolocation of the patient’s hometown to enable monitoring for aftercare.

Server and facilitator business practices would also need to take into consideration compliance with HIPAA, PIPEDA, EU/GDPR and other regulatory compliance for privacy, data security, right to opt out, and right to be forgotten.

Another consideration is that eventually, over time, the app will no longer be used by a user unless another medical trip is contemplated and scheduled with the same facilitator.

Still another consideration would be that notifications would need to be scheduled and coordinated with the end user’s time zone and phone settings for “do not disturb” periods for medication reminders and appointment reminders, but also to break through for security alerts to be delivered in real time when urgent.

A place to store reference documents available to all users (e.g., “Shelter in place” tips and other informational resources) shared with all users would be necessary. In addition, a place to store medical records and DICOM viewer for images would be needed to store and share medical records, medication logs, prescription discount card, and diagnostic images unique to each user and shared easily upon demand.

The consultant’s role

The consultant can serve as a general contractor and subcontract (and pay) the programmer to write the code once the needs are specified. Since, in this case, the consultant will be the developer and project “owner” and will ultimately “own” the intellectual property, the consultant can advance the payment to the subcontracted programmer.

If, on the other hand, the relationship was a “work for hire” and the consultant would relinquish the intellectual property and the patent registration, the consultant would be hired to do project management only, and required (if based in the USA) to pay the programmer from the proceeds of the payment from the client.

In that case, an initial retainer deposit and transparent statement of expenses might be necessary. The amount would be based on the quote from the programmer plus some buffer budget in case the project must be redone or reassigned or to cover “scope creep”. Monies not used as intended (to pay subs) would rightfully be returned to the client if funds remain after delivery.

The real value of the consultant is loaded heavily on the basis of understanding the facilitator’s goals. Some clients may want to be the first to enter an industry with an app. Others may require the highest standards of quality, reliability, privacy, security and operational stability. Some may be focused on retaining existing customers, while others want to attract new customers. Each of these objectives and key results (OKRs) affect the product design and implementation in myriad ways.

The consultant as project manager must also document all functionality, security and feature requests because this will be helpful in asserting patent application claims going forward. The consultant must also develop and obtain agreement on deliverables and the timeline. This will entail refining the scope of work to a level that clarifies which features are  absolutely essential and must be built into the minimum viable product (MVP), and what features are “nice to have” if there is time remaining at the end of the project.

If every feature is a “must have,” the consultant will either need to push the facilitator to prioritize something or make sure the consultant has reserved ample development, and add some modest time buffers to unanticipated programming delays or even finding a replacement programmer if the initially subcontracted programmer “flakes out” and fails to deliver or delivers a substandard or otherwise useless product and bench scheduling. If everything proceeds without delay, the consultant will deliver ahead of schedule and earn extra points for early completion. Project estimating skills are critical and the consultant will likely over- or under-estimate time requirements. This should be taken in stride.

Ideally, the consultant would understand medical tourism operations, risks and workflows. There aren’t many such consultants with this expertise worldwide, who also do this sort of project management or product development. The consultant’s expertise adds value and reduces research and development costs while a less knowledgeable consultant that is unfamiliar with the risks, operations, user psychographics, and use cases will likely need to charge more but deliver less value in the same time frame.

If the facilitator cannot explain user workflows and how the app will be used by their clients and on which devices, surprises and incompatibility issues are at greater risk. In this case, a facilitator with 1500 clients per year should be able to know their customer personas and workflows. On the other hand, a novice facilitator with a few clients per month would only be guessing and wouldn’t know what they don’t know. But then again, a novice facilitator will likely neither have the awareness of the value that such an app could deliver in terms of branding, will not be looking several years in advance and assume viability and sustainability, may overestimate growth over the first years, and likely not have the capital to pursue such a project on their own.

At a minimum, the facilitator must know their buyer personas to be able to tell the consultant what devices and models of phones the medical travel patients will use, their age, gender, user experience and comfort with iPhone and Android apps.

The consultant will also need to plan for costs and time associated with distribution and approval and hosting fees on the Apple and Android app hosting sites. Also any artwork, images, graphic elements, fonts, etc., that must be licensed and renewed annually must be accounted for. The consultant will also need to subcontract designers who may play specific roles across areas such as design, development, documentation and testing.

Before any code is written, the subcontracted designers will work to create the protoype look and feel through layout, visuals, and interactions. Designers answer simple questions like “Should the navigational menu be at the top of the page or the bottom?” to more complex questions like “How can we convey a sense of simplicity, creativity, and reliability?”

In general, designers answer these types of questions by interviewing users, creating many designs of the same product idea, and then making a final decision by choosing one design. In the case of this prototype, users will not be consulted directly, so the facilitator takes on the role of user proxy. That means it is even more critical for the facilitator to be experienced and know their customers – a byproduct of deep brand development and experience over time.

There are also several types of designers that the consultant may need to subcontract:

1. User interface (UI) and user experience (UX) designers who deal primarily with “look and feel” and with layout
2.  Visual designers who deal primarily with creating the final graphics used on the app and creates final versions of icons, logos, buttons, typography, and images.
3.  Interaction designers who deal primarily with interactions and animations based on user inputs and use case. 

After the design is complete, the front-end and back-end developers transform the designs to reality. Front-end developers usually code in HTML, CSS, and JavaScript, and convert the design into a user interface. They ensure that the application appears and operates consistently across devices (desktop, laptop, and mobile), browsers (Chrome, Firefox, Safari, and so on), and operating systems (Windows, Mac, and so on). All these factors, especially increased adoption of mobile device. But they also result in thousands of combinations that must be coded for and tested because every device, browser, and operating system renders HTML and CSS differently. That takes time…and money. Who will pay and how much will be the appropriate share in this particular collaborating arrangement?

On the other hand, back-end developers add functionality to the user interface created by the front-end developers. Back-end developers ensure that everything that’s not visible to the user and behind the scenes is in place for the product to work as expected. Back-end developers use server-side languages like Python, PHP, and Ruby to add logic around what content to show, when, and to whom. In addition, they use databases to store user data, and create servers to serve all of this code to the users. The documentation from both front-end and back-end developers will also be helpful to complete claims asserted in the patent application. The reason I continue to mention patent development is because if the product is successful in meeting the facilitator’s OKRs, the value of the intellectual property will be increased with a fully-executed patent and a large user base in the event of an acquisition by investors.

For those startup facilitators who broadcast market to the world under the misassumption that “everyone” is their target and prospective customer, and who has not undertaken branding and brand creation research and doesn’t have any customers to “know”, the designers will leave such a meeting without the information they need to proceed and the project will likely fail going forward.

Testing

Testing and assuring quality, reliability, and compatibility and keeping up with Apple and Android updates occurs after the prototype has been developed and released in early beta. The consultant should be prepared to oversee and direct this process, list all the cor user tasks and flows, and find testers who may more closely resemble prospective patients in addition to the commissioning facilitator client.

For the facilitator to roll this untested version out to actual clients could be viewed as unprofessional and detract from brand image instead of be interpreted as novel, leading edge and innovative. Medical travel clients are not guinea pigs and shouldn’t be asked to test anything during the course of their episode of care.They are ill, injured or otherwise preoccupied with the matter before them and are not appropriate to be called upon to volunteer to be your test subjects.

During the testing phase, finding testers who will honor and comply with non-disclosure requirements is a significant security concern. There is a risk that you may engage an unscrupulous, unethical freelancer who agrees to test your prototype and then they reverse engineer the intellectual property and attempt to make a profit from the sale of or trade of confidential information. Freelancers without assets to protect are the most risky, as they could be sued and have little to lose even if the consultant prevails in winning a guilty verdict. Freelancers in other countries would be even more challenging because the contracts protecting intellectual property rights may be interpreted differently in different countries.

Start by protecting the work and intellectual property with the appropriate documentation and a preliminary patent application. An attorney can assist you with this in short order. Then, assign the testers to begin testing the prototype on different browsers, devices, and operating systems to find errors. 

Your testers should be required to compile the newly discovered bugs and provide feedback to the developers, who prioritize which bugs to fix first. Critical bugs must be fixed immediately. Minor bugs can be scheduled as updates or later releases. Leaner development also teams can include feedback systems and collect error reports from users through the adoption of feedback forms and.or automated reporting by permission allowed through an opt-in to send data in the background or EULA agreement.

Another time and expense consideration is the instruction manual or user manual that teaches end users how to use the app and maximize performance. This form of technical writing is also going to be useful in the patenting process, so make sure you have a professional technical writer subcontracted or otherwise available to prepare this documentation.

At a minimum, the following steps would be required for this app:

1. App downloading and activation
2. A button that initiates the app to begin executing other steps necessary for functionality
3. Determining the user’s location. Since it is not fixed and changes rapidly, this is more complicated. The user may be walking or driving.
4. The location of the hospital, clinic, retailer, hotel, restaurant or other point that must be identified. As a prototype being used in a pilot, a small number of reference points can be included to limit the scope (and expense) of the field testing. Assuming the pilot field test is successful, the developers would need to expand the number of reference outlets offering coupons or that should be included in notifications. Locations and suppliers would need to be updated regularly for all destinations where the facilitator intends to distribute the app for client use. Who pays the labor and costs for adding additional sites and testing the updates must also be decided in advance.
5. Calculating distances between the end user’s current location and the reference points will be the “customer distance”.
6. Monitoring several minutes of customer travel into a distance labeled “threshold distance” so that notifications, coupons and other information can be served to the end user in real time. The app should be able to convert time into distance and should be able to adapt for variances by common modes of transportation and by location. For example, traveling Sukhumvit Road in Bangkok between the hours of 3pm and 7pm is very different from travel occurring at “off peak” hours.
7. When the customer distance is less than the threshold distance, offers and notifications are sent to the end user. The same would apply to a security notification. The customer distance and threshold distance for the weather event, civil disturbance, risk or other circumstance would need to be entered into the system first, and then the whereabouts of the end user ascertained to provide relevant information based on proximity to the event coordinates.

This is where many software logic mistakes could arise. When developers forget a step or users decide that the app is expected to behave in a certain way and it doesn’t, these can either be critical updates or scheduled enhancements for a later date.

Conclusion and summary

From the above example, one can easily see how complicated it would be to develop an app like this for use in medical tourism. You may read blog articles that suggest that a way to differentiate your brand is to create an app. Not so fast, my friends!

I hope that I have alerted you to some of the considerations you’ll need to sort out so you have more realistic expectations of what is involved. Some app developers pitch me from India, Bangladesh, Pakistan, the Philippines and other places through LinkedIn and my websites in an attempt to make me believe that they can build an app like this for me or my clients in 5-6 hours at a price range of $350.

You may receive similar overtures. I hope you now better understand that 5-6 hours and a price range of $350 is either a “bait and switch” offer or an offer to create a totally useless deliverable. If it were possible, I would quit the business I am in and pay the $350 and build ten of them at that price!

The way I see it, an app such as this would require minimum capitalization of $75,000 or more to complete and release, plus additional capitalization for maintenance and hosting on the Amazon S3 Cloud. I know of no medical tourism facilitator currently in business that I am aware of who could cost justify such a commissioned assignment to provide for patients. The market is just not at this stage of development nor do I expect it will be for years to come, if ever. The hours charged for the actual programming and writing of code may be a few hundred dollars, but as you now realize that’s the tiniest fraction of the cost for the total project.