Med-Tech Innovation Technology for assisted living
Figure 1: The dallas reference architecture
step, many stakeholders were concerned about the implications (Figure 3). Which applications would invoke the Medical Device Directives, and what would this mean? Is it just the app that is certifi ed as complying with the Directives, or the combination of the app, operating system and phone hardware? Is it possible to safely and compliantly install a health-related app onto a user’s smart phone and still let him/her use it as a phone? What happens if the user or the mobile network operator upgrades the operating system on the phone? What about the back-end servers and the applications running on them?
By talking to stakeholders, reviewing all the guidance
a directly implementable interoperable ecosystem, but instead facilitates conversations between stakeholders, which have proved extremely useful. Intellect (the ICT industry trade association) subsequently published a paper “The NHS Information Evolution,”2
which included
an aspirational “Future Patient Journey” that readily maps onto the dallas architecture. The NHS Wales Informatics Service was also able to map some work that it was doing onto the same architecture. Both mappings are available from the i-focus website, together with presentations:
www.architecture.ifocus-dallas.com. The architecture describes a system whereby authorised “User Components” (applications used by individuals) communicate securely with accredited “Service Components” (providing transactional services or access to information sources). Service Component developers either implement a standard web service application programming interface (API), or publish their own. User Component developers build applications against these APIs, mixing and matching information from sources they consider appropriate, presenting information and incorporating transactions to their users in compelling ways.
It is envisaged that only accredited User and Service Components will be able to utilise the system so that security and privacy of information and the veracity of any supplied information and advice are assured.
Other fundamental building blocks The other four work areas look at specifi c areas of interest across all the dallas stakeholders, or topics that were identifi ed as fundamental blocks to large- scale deployment. White papers (profi les) on all of these topics are freely downloadable from www. profi
les.ifocus-dallas.com and feedback is welcomed. The Reference Architecture proposes use of a federated identity management system to authenticate users, because the Government is proposing to roll-out the Government Digital Service across all government services (Figure 2). This will allow individuals to use an existing digital identity, rather than creating yet another username and password for each application and/or service. This is discussed further in work on Identity and Consent, which can be accessed at
www.profi les.
ifocus-dallas.com.
Although the use of consumers’ own electronic devices was universally accepted as being a necessary
28 ¦ September/October 2013
www.med-techinnovation.com
from the authorities and getting advice directly from the Medicines and Healthcare products Regulatory Agency (MHRA), the i-focus team has been able to pull together some guidance on the implications of the Medical Device Directives when using consumers’ own devices (see guidance at
www.profi
les.ifocus-dallas.com). This shows that, in reality many of the use cases and scenarios that are being contemplated in dallas fall outside the remit of the Medical Device Directives, and where the Directives do apply, the applicability can be ring-fenced if enough thought is given to designing an appropriate architecture. Then there is the question of how to develop a multiplatform application in a timely and cost-effective manner while ensuring its user interface meets the differing norms of the various platforms (Figure 4). What are the pros and cons of developing an HTML5 web-app versus native apps for each platform? The dallas paper on multiplatform service delivery, which can be viewed at www. profi
les.ifocus-dallas.com, helps to clarify things for those not already immersed in multiplatform mobile app
Figure 2: The proposed federated identity and consent system
Figure 3: Example scenario of an app on a mobile device being used for medical purposes
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50