Abstract. Introduction

Transcription

1 Map that App event hosted by Oxford AHSN 29 th January 2014 Healthcare smartphone app development Prepared by: Emma Roberts 7 th January 2014 Abstract This report aims to highlight some of the key issues in the development and commercialisation of healthcare smartphone apps. It will briefly discuss the process of developing healthcare apps, including potential challenges in app development arising from the Medical Device Directive and CE marking. Finally it will highlight, through two examples of trailblazers, important factors that should be considered in healthcare app development. Introduction 50% of attendees of the Map that App event indicated that they were either developing or considering developing a healthcare app. As a result, the event was targeted at individuals at the conception and ideation stage of app development. The expansion of healthcare smartphone apps is a rapidly developing area. There were for example, 44 million healthcare apps downloaded in This is predicted to grow to 142 million in Oxford AHSN themselves indicated that the majority of disclosures they now receive relate to apps. Figures also indicate an increased willingness of clinicians to use medical apps in clinical practice. In 2010 for example, 81% of Clinicians indicated that they used medical apps in clinical practice. In 2012, this figure increased to 91%. 3 The increased use of apps therefore presents a number of emerging challenges in healthcare: Patient expectation of healthcare apps is increasing. Healthcare apps need to meet patient expectation in terms of functionality, design and utility. Patient and consumer safety should be paramount but it is not. At present for example, there are 97 million un-validated healthcare apps. 4 This means that they have not undergone an extensive clinical safety check. Those involved in healthcare app development are now looking to facilitate a safer environment for healthcare apps to operate and sustain themselves after deployment. This was communicated in the discussion of the process of development and by the two trailblazers at Map that App. 1 Brian Dolan, Report: 44M health app downloads in 2012 (mobihealthnews, 30 Nov 2011) accessed 06 Feb ibid. 3 Tony Hill, Map that App Road Map report (2014) (publication pending) 4 Ralf-Gordon Jahns, The Market for mhealth app services will reach $26 billion by 2017 (research2guidance, 7 March 2013) / accessed 06 Feb

2 1. The process of developing healthcare smartphone apps Stage 1 Pre-development This stage of app development is the same initial phase that the SW AHSN encourages innovators to do when it provides innovation support. This includes advising app developers to run a google search to see if the app already exists and to consider potential stakeholders. In essence, stage 1 is about producing a valid business case. Stage 2 & 3 Design and development phase & user testing At these stages, the functionality of the user should be a key consideration. Screen shots can be an effective way of identifying if an app works for users. The majority of healthcare apps are downloaded on the basis of peer to peer referral. 5 It is essential therefore, that the interface of an app is easy to use. Software developers are now trying to personalise apps as much as possible. Stage 4 Clinical safety management The importance of conducting a security a review of healthcare apps must not be underestimated. This can be highlighted by the media attention attracted by Happtique. 6 This mhealth platform in the U.S. suspended its health apps after a software developer exposed the security shortcomings of how its apps collected data. 7 Usernames, passwords and data were all stored in plain text. 8 This meant that the data could be read by anyone. Stage 5 Medical devices Why is this an issue? This stage is only relevant if the app is going to be deployed externally. If an app is intended to be deployed internally i.e. within a Trust or intended to be used for research purposes only, it does not have to comply with the Medical Device Directive (93/42/EEC). 9 If an app is going to be deployed externally however, it needs to comply with the Medical Device Directive as implemented into national law in the UK through the Medical Devices Regulations Article 1 (2) (a) of the Medical Devices Regulations indicates that some apps may fall within the definition of a medical device. 11 The relevant section of the article is as follows: 5 see Guy Smallman, The benefit of apps in healthcare The Guardian (London, 21 Aug 2012) 6 Happtique Suspends Mobile Health App Certification Program accessed 06 Feb ibid. 8 ibid. 9 Council Directive 93/42/EEC of 14 June 1993 concerning medical devices OJ L 169 available at: 10 The Medical Devices Regulations Supra note 9, Council Directive 93/42/EEC 2

3 [A] medical device [is] an instrument, apparatus, appliance, material or other article, whether used alone or in combination, together with any software necessary for its proper application, which - (a) is intended by the manufacturer to be used for human beings for the purpose of- (i) diagnosis, prevention, monitoring, treatment or alleviation of disease, (ii) diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap, (iii) investigation, replacement or modification of the anatomy or of a physiological process, or (iv) control of conception If an app being externally deployed is deemed to fall within Article 1 (2) (a) it must be CE marked. The legislation places an obligation on manufacturers to ensure that these devices are safe and are also CE marked before they can be put on the market in any EU member state. 12 This is regardless of whether the app developer is intending the app to be offered free of charge. As indicated above, this only applies if the app is being deployed externally. Bulletin no. 18 MHRA provides a loophole that means smartphone apps being deployed internally or being used for research purposes do not need to comply with the Directive. 13 CE Marking In short, if the app being developed falls under the Medical Devices Directive, it must then follow a complicated regulatory process. This includes being categorised into classes according to the degree of risk inherent in the device MHRA. 14 Once classified, the MHRA will decide if the medical device app can be CE marked. At present, the majority of healthcare apps have been developed as lifestyle apps i.e. calorie counting apps, rather than as medical devices so they do not have to comply with the Directive. This has been the approach of NHS England via the NHS Choices app library. 15 NISE Senior Innovation Manager, Tony Hill indicated that there is a general reluctance of NHS organisations/universities to have to comply with the Directive. No organisation wants to be named as an organisation that takes risk for not following the correct procedure. Stage 6 Registration and app platforms This stage applies to apps that do not fall within the Directive or apps that do fall within the directive, but have now been CE marked. This stage relates to app registration. With patient safety in mind, a number of apps are now having their registration refused by a number of platforms if they do not fulfil certain safety criteria. 16 Apple have for example, now placed more stringent measures on apps seeking registration to ensure they have followed correct procedure. 17 This is reflected in a U.S. study undertaken by 12 MHRA, How we regulate medical devices 13 See MHRA, Borderlines accessed 05 Feb 2014 & Tony Hill, Map that App Road Map report (2014) (publication pending) 14 MHRA, Medical Device Classification accessed 06 Feb Choices health app library accessed 06 Feb supra note 3, Tony Hill, Map that App Road Map report 17 Devices 4 Limited, Regulation of health apps: a practical guide (January 2012) available at: accessed 07 Feb

4 TRUSTe. TRUSTe s 2013 Consumer Data Privacy Study indicated that 78% of mobile users will not download an app that they do not trust. 18 Tony Hill also indicated that more NHS organisation are also implementing mobile management solutions (MAM/MSM) that indicate to staff which apps are safe to use. 19 There are many benefits in developing NHS branded smartphone apps. The NHS is a trusted brand and implies that extensive clinical safety checks have been carried out. Potentially, this means that mobile users are more likely to download healthcare apps that have been NHS branded. As mentioned above however, this also carries with it a high risk if an app is unsuccessful. NHS organisations do not want to be name blamed for the failure of an app. In particular, if the correct procedure has not been followed, there are security issues with the app and quite simply, does not fulfil its intended purpose. Stage 7 Deployment and sustainability There is a direct relationship between how an app is deployed and how this will impact how a healthcare app can continue and be sustained. It may be necessary to consider creative ways of sustaining an app once registered. App developers for example, may need to consider following a commercial approach or a service/products approach in order to ensure the app can continue to be provided. These both however, raise important issues: The commercialisation approach A key point raised by NISE Senior Manager, Tony Hill was whether consumers would be reluctant to pay for healthcare apps. He suggested that consumers would be more willing to pay if branded with an NHS logo, as long as the pricing level is right. 20 Arguably, this is only viable if the benefits of paying for the app are communicated to the consumer i.e. that it is CE marked and has therefore undergone extensive clinical safety checks. Another issue raised however, was the appropriateness of commercialising health apps at all. If an app is patient focused for example, how appropriate would it be for an app to contain adverts? The service/products approach In this approach, an individual purchases a product, such as a blood pressure device and the app is provided as part of the purchase. 2. Important considerations raised from the two case studies at the event Oxford AHSN invited two trailblazers to discuss their experience of app development: 18 Press Release: Consumers More Concerned about Mobile Privacy than a Phone's Brand or Screen Size available at: 19 supra note 3, Tony Hill, Map that App Road Map report 20 supra note 3, Tony Hill, Map that App Road Map report 4

5 South Central Ambulance Service Foundation Trust (SCAS) developed an app which locates the nearest AED. This was developed with Oxford AHSN and a software developer. ( AED Locator ). 21 Diabetes Network developed an app in partnership with diabetes UK, Sanofi and Oxford AHSN. This app is a blood glucose measurement game for children with Type 1 diabetes. ( Monster Manor ). 22 Both trailblazers raised some interesting points to consider in the development of their respective apps. I have divided these into what I consider to be strengths and challenges. Strengths Organisational support Secure data input Campaigning Timescales Media attention Crucial to the development of the AED Locator app was the organisational support they received from the British Heart Foundation through the Heart Start Campaign. They also generated support through community partnerships. This was the same for the Monster Manor app. This game was developed as part of a partnership between Oxford AHSN, Diabetes UK, Sanofi and gaming firm Ayogo Health. The two trailblazers therefore played into their existing links and did not encroach on the territory of existing organisations. The SCAS was able to ensure secure data input by using the existing data of organisations with their co-operation. SCAS also ensured that they were not liable for inaccurate data through setting up a disclaimer. This ensured they had a clear understanding with users that the data is only as good as is told to the SCAS. One of the key strengths of the AED Locator app is the campaign SCAS are running alongside the app. This is seeking to change people s misconceptions about cardiac arrests and encourage individuals to use AEDs in the event of cardiac arrest. SCAS identified that the existence of the app is pointless if the general public will not use AEDs. The AED Locator was able to be developed quickly because most of the data was given by organisations. SCAS identified however that cleaning the data was the most time consuming aspect of development. It is an aspiration of SCAS that the AED Locator app will attract great media attention once the AED Locator has been used to save a life for the first time. SCAS highlighted that this will be an excellent way of generating more funding this project. 21 Declan Heneghan, Lifesaving app launched by South Cenral Ambulance Service (13 Nov 2013) see 22 Monster Manor app set to be a game changer in the management of diabetes for the smarter igeneration (15 Oct 2013) 5

6 Challenges Research Local or national Funding In the pre-development phase of the AED Locator app, SCAS indicated that there was an absence of information online relating to existing apps relating to cardiac arrests. It was difficult to ascertain therefore if there was a gap in the market for this kind of app. A key consideration of the AED Locator app was whether they should deploy the app locally or nationally. Ideally, SCAS initially wanted the app to be deployed nationally but recognised that they did not have the capacity to maintain this app at the national level. Neither apps received any NHS funding. SCAS therefore did not allocate a particular budget to the development of the AED Locator. SCAS were however, creative and generated funds through donations by community engagement. The software developer also provided his services for free. Similarly, the Monster Manor app was funded through sponsorship. Concluding remarks The reality is that organisations, academics, the right stakeholders and software developers need to collaborate in partnership with each other in order to develop healthcare smartphone applications successfully. This will ensure the correct procedure is followed in the development stages and also facilitate a strong foundation for healthcare apps to sustain themselves after being deployed. 6