METHODS
We here aim to provide a starting point for these deliberations by distilling key strategic priorities for developing a more integrated national approach. To achieve this, we build on recent work conducted by the American Medical Informatics Association (AMIA) exploring potential policy frameworks and associated strategies for PGHD,16 and a white paper for a PGHD Policy Framework published by the U.S. Department of Health and Human Services’ Office of the National Coordinator (ONC) for Health Information Technology in collaboration with Accenture.15 North American deliberations were the focus of this work as they are relatively advanced in national policy deliberations in relation to PGHD. We summarise five key priority areas emerging from these frameworks and place these in the UK context to illustrate how national strategy can build on existing challenges, initiatives, technologies, expertise and infrastructures. The list of priority areas is not intended to be exhaustive and we acknowledge that areas may overlap. Challenges and recommendations are summarised in Figure 1.
Priority 1: Creating regulatory environments that promote information integration across data sources without stifling innovation
PGHD may be viewed as an addition to existing health information infrastructures that are built, created and maintained by a variety of stakeholders, including patients themselves.17 Developing data standards that enable structured data entry and information sharing across various applications is key to achieving a degree of information integration across information systems.
Since April 2017, the national governance arrangements for information standards in healthcare, data collections and data extractions in the UK are overseen by the Data Coordination Board. There is now also an NHS Digital Apps Library with NHS approved patient facing functionality.18 However, although some progress has been made in relation to creating unique patient identifiers and developing data standards in clinical applications, there are currently no national or international standards that promote the exchange of information between PGHD applications and EHRs. This may partly be due to the reluctance of developers to open up their systems to third-party suppliers, limiting seamless exchange between mobile devices and EHRs.19 Many developers address international markets and there is substantial variation in the structure of health care systems, legal requirements and the interoperability afforded by the EHR systems in use. Hence, sharing the PGHD is often limited to emailing information to relevant stakeholders, be they doctors, carers or family members. As a result, existing health-related data are held in silos and there is, therefore, now an increasing international drive to open up Application Programming Interfaces (APIs).20 The newly established API Lab run in partnership between NHS Digital and INTEROPen and the Substitutable Medical Applications, Reusable Technologies on Fast Healthcare Interoperability Resources open specifications to integrate health information technology systems is likely to present an important national first step towards addressing this issue.21,22 Going forward, the adoption of internationally accredited standards is critical in order to incentivise developers and minimise variation across settings. Although regional variations are likely to exist, such standards can facilitate the implementation of core software capabilities that can facilitate data exchange.
As PGHD is an emerging area, there are also currently no clear liability laws surrounding patient facing devices and approval mechanisms are convoluted, which may further prevent developers from actively pursuing strategies to integrate patient facing technologies with clinical systems.23 This may also prevent healthcare professionals from using these data. In the European Union, apps that transmit clinical information are currently classed as medical devices and need approval by the Medicines and Healthcare products Regulatory Agency – a very lengthy process.24,25 In terms of the development of clinical apps, the normal industry practice of rapid prototype development with iterative cycles does not fit well with ethical requirements, which for patient apps need precise descriptions of technology for approval. Streamlining these mechanisms will, therefore, be critical in stimulating a vibrant ecosystem, whilst appropriately regulating approvals, liability and data sharing.
Priority 2: Developing data governance and ethical frameworks that allow data sharing across settings
In relation to PGHD, there is at present no coordinated framework for data sharing across agencies and settings due to infrastructural considerations discussed above. Current UK data protection frameworks are designed to regulate data access and sharing of medical information in clinical applications26 but these now need to be extended to cover a range of patient facing technologies and associated PGHD that will move between individuals, settings and technologies. These frameworks need to be sufficiently flexible. For instance, existing guidelines treat all healthcare data equally although not all data are equally sensitive, for example, patient activity levels.27 Frameworks also need to ensure a balance between patient data being kept safe and adequately protected, whilst still promoting data liquidity.
There is further an urgent international need to develop robust ethical frameworks, closely aligned to legal frameworks, for emerging medical technologies and associated PGHD. Establishing a national ethics working group will be important, working collaboratively with system developers to anticipate emerging ethical challenges and mitigating potential risks early.
Priority 3: Standardising person-centred methods and outcomes
In the face of questions surrounding the validity and accuracy of some PGHD devices and the emerging nature of efforts to incorporate PGHD with EHRs, there is an important need to strengthen the empirical evidence base surrounding various applications.16,28,29 In order to aggregate evidence and align with different functionalities, outcome measures should where possible be standardised and build on existing national work surrounding, for example, Patient Reported Outcome Measures led by NHS Digital.30 Here, initial efforts could focus on building an evidence base surrounding the most commonly used functionalities (e.g. apps) and conditions, where PGHD has been tested in small-scale pilots (e.g. asthma, diabetes).8,9,31
This work needs to ensure appropriate coverage surrounding patients, in order to define core datasets that are relevant to specific health outcomes, and clinician-informed, in order to ensure that information generated by patients is used by clinicians (see Priority 4 below). Drawing on theory-informed approaches to evaluation will be extremely important in this context, in order to learn from experience and generalise between settings and across conditions.32 Such work should also draw and build on ongoing international evaluation efforts.
Priority 4: Incentives for various stakeholders to create, use and re-use PGHD
In order for PGHD to be created, used and re-used effectively, it is important to map benefits and challenges across different stakeholders.15 These mapping exercises must be more closely aligned with efforts to develop an empirical evidence base and also with health system structure, ensuring that generation and use of PGHD are appropriately incentivised.
Patients need to be motivated to continuously generate PGHD that are perceived to be useful to clinical users. While education matters, it is even more important that patients perceive PGHD to be useful and meaningful for themselves. More active promotion of incentives amongst less motivated users may also help. Such efforts could build on existing work surrounding perceived valuable features of mobile applications among the general population in order to promote lasting behaviour change.33 These may include repeat prescription ordering, appointment making and/or gamification techniques.
Clinicians need to be incentivised to draw on data generated by patients and this can only be achieved by developing tools that integrate effectively with existing workflows and that produce data that can be translated into meaningful information that is helpful at the point of care (see Priority 5 below).
Developers need to be incentivised (or forced if interfacing with the NHS) to open APIs (as discussed above) and develop tools that make it easy for patients, clinicians and researchers to produce, use and re-use PGHD. They need to want to create patient-facing applications that are designed to integrate with clinical systems, whilst still making a financial profit. This is particularly true in increasingly regulated international environments, where incentives will need to match suppliers’ level of effort required to navigate these challenges.
Regulatory environments can stifle development in this respect and it is, therefore, crucial that strategic frameworks remain flexible and responsive to emerging needs.34 Here, it also needs to be kept in mind that there are many challenges with the development of open APIs, including risks surrounding the breaking of application functionality with the introduction of new interfaces or features, increased security risks and security complexity, unexpected/undocumented releases and the support needed for this increased complexity. There are further potential risks associated with data protection and these need to be carefully tracked and incorporated in emerging regulatory frameworks (see Priority 2).
Priority 5: Collaboration across stakeholder groups to create tools that work for all
Patient and provider facing technologies need to be usable as otherwise they will be rejected or used in a way that do not yield sufficient high-quality data used in other ways than intended, leading to potentially adverse consequences for patients and professionals.35 However, existing EHRs have been found to lack usability/integrability and often have difficulty integrating effectively with healthcare professional work practices.36 The development of technology, therefore, needs to be informed by user-centred design principles and this requires close collaboration between stakeholders (developers, patients and clinicians) to ensure that information is collected and presented in a format that aligns with user needs.37
Information presentation of PGHD in clinical systems is likely to pose the biggest challenge, as clinical users can feel overwhelmed being presented with large amounts of unsolicited data in electronic systems, which may distract clinicians and result in patient harm.38–40 This is complicated by the variety of stakeholders and different resulting data needs – each provider will need different contextualised information depending on the task at hand.16
Currently, most data from patient-facing devices are presented in PDF format which clinicians can open when/if they feel appropriate. However, this means that important opportunities for intervention may be missed. It is, therefore, critical to draw on the existing human factors literature to build an evidence base surrounding technical functionality and associated perceived value to individual users across settings.40 Work surrounding alert fatigue in clinical decision support systems may also offer valuable insights in relation to designing information presentation.41 There is also an urgent need for summarised data which can be presented periodically through normal data management channels (e.g. like lab results and letters currently are), which are harder to ignore by clinical users.
Ideally, the way information is presented is flexible and sensitive to individual contexts/roles so that different clinical users only see patient-generated information they need for the task at hand. In this respect, establishing processes for when information is displayed in clinical systems can be extremely helpful and this has international relevance. For example, PGHD may be most appropriately selectively presented to clinicians when the patient experiences exacerbations or in different levels of abstraction that can be selected according to individual needs/preferences. In this respect, machine learning may facilitate self-management (e.g. by helping patients to make decisions as to when to consult a clinician) and it may also help to tailor insights from data to roles of clinical users.
