The Journal of mHealth Vol 2 Issue 1 (February 2015) | Page 26

From Pilot to Take Off: Watch mHealth Fly in 2015
Continued from page 23

how can you take the service forward in a cost-effective way?
Putting the patient first
When it comes to scaling out mHealth solutions across borders,
it is vital that patients are kept central to all design decisions.
Before scaling a solution, the mantra should be ‘pilot, pilot,
pilot’. It is naive to think that an app will be road-ready first time
around, and it should be tested against different markets and
territories before being rolled out internationally.
Vendors should identify who the app services and engage with
patient focus groups to ensure the app meets their needs, as it
is these users that the service is being designed for. Language
should be taken into consideration – as it is rare for vendors to
have multilingual teams. Most build their apps in Anglo-English,
which often doesn’t translate well into other languages. Additionally, many countries have no concept of AM and PM, so
a 24 hour clock is required; and a Personalized Identification
Number (PIN) means little across huge swathes of the world.
Finally, End-user Licence Agreement (EULA) may mean nothing in Europe.
Converting solutions to work across borders
What, then, will make an mHealth cross-border conversion successful? There is a number of operational factors that are crucial
elements of any multi-territory program:
»» Users’ data allowance: A scaled-out mHealth solution
should have an added value through enhanced content.
For example, viewing videos outside of WIFI connection could incur additional charges, therefore cross-border
multi-territory programs should have measures built in to
either block the content or to issue a warning if a user is
viewing content which may impact their data allowance.
»» Level of device integration: Data collected in form of medical device readings can be an important part of any mHealth
service, hence the impact of medical device integration for
global mHealth programs needs to be considered.
»» Data synchronisation: It is not just a case of translating
the service, full service localisation should be considered as
centralised systems must be able to cope with data arriving
in different formats across broader time zones.
»» App and battery life: It is essential to understand how
peripheral device integrations can affect battery life, and
what impact on a device’s battery an mHealth app will have.
Regulation: a varied landscape
Depending on which territory an mHealth solution is being utilised in, there may be specific requirements around where the
patients’ personal data is held, and who has access to it. Different territories have varying regulatory requirements regarding data protection and different data protection considerations
should be built into the programs at source. For example, economic areas with heightened data protection requirements, such
as the EU, can pose additional challenges when trying to adopt a
global approach for mHealth programs. Within the EU, despite
agreements being in place for the international transfer of personal data (e.g. Safe Harbor), the patients’ perception of the
protection applied to their data when it is placed outside of the
EU can create a barrier to adoption.

24

February 2015

The success of any mHealth solution comes down to patients
being able to use it within different countries. When it comes to
the design, these different levels of data protection can add a
level of complexity that simply isn’t needed. There has to be an
understanding right at the first-stages of designing cross-border
mHealth solutions about what is going to happen to the data
and where it’s going to reside, as it can fundamentally influence
the design process.
Another regulatory consideration when rolling out mHealth
programs across international borders is the country-specific
End-user License Agreement (EULA) and policies. When it
comes to sof