From interoperable data to continuous care: a responsive implementation approach to personal health data spaces

Personal health data spaces (PHDSs) promise to give individuals meaningful control over longitudinal health information while making heterogeneous data available across settings of care.The promise is consequential: continuity may improve when a person can authorize access to clinical records, patient-reported information, wearable data, and other sources without each transition requiring a new reconstruction of the record. Yet technical availability is not equivalent to continuity. A PHDS can be interoperable, secure, and formally patient-controlled while remaining difficult to use, weakly integrated into clinical work, or unevenly accessible. The central challenge is therefore not only to build PHDSs, but to implement them so that data become usable relationships and coordinated action.The articles in this Research Topic make that challenge visible from complementary directions. Ambalavanan et al. propose a modular, ontology-driven front-end architecture linking user experience, security, data management, interoperability, analytics, and scalability (1). Lin et al. describe a blockchain-supported dynamic consent framework through which participants can modify permissions and data uses over time (2). Ruan et al., studying a population at high risk of stroke, show that proactive health behavior is associated with health literacy, social support, self-efficacy, and material circumstances (3). Read together, these contributions suggest that a technically capable data space will produce continuity only through an implementation system that makes participation understandable, supported, actionable, and revisable.This Opinion argues for a responsive implementation approach to PHDSs, in which technical capabilities, governance arrangements, organizational workflows, user supports, and learning processes are deliberately connected to improve care continuity. The SPHERE model -Social Prescribing and Health Equity through Responsive Evaluation -was developed for policies enabling social prescribing, not for digital health architecture (4). Its value here is therefore not as a template to transfer wholesale. Rather, its eight-part logic offers a useful viewpoint: durable effects emerge when foundations, infrastructure, community co-production, context, implementation strategies, process measures, outcomes, and feedback loops are deliberately connected. Applying that logic to PHDSs shifts the evaluative question from whether a data space exists to how, for whom, under what conditions, and through which mechanisms it improves continuity, and how implementation should be revised as evidence and surrounding conditions change.PHDS discussions often separate technical design from "adoption," treating implementation as a downstream step. This division is misleading. Decisions about identity verification, consent granularity, provenance displays, terminology services, access delegation, and clinical integration distribute work and authority among patients, caregivers, clinicians, organizations, and data stewards. They are implementation decisions because they shape who can participate, what actions are feasible, and whether the technology fits existing routines. Frameworks such as the updated Consolidated Framework for Implementation Research and NASSS similarly emphasize that technologies interact with recipients, organizations, wider systems, and change over time (5,6). Human-factors approaches further show that outcomes arise from interactions among people, tasks, tools, organizational conditions, and environments rather than from any component alone (7).Ambalavanan et al.'s layered architecture illustrates the point (1). Semantic standards may allow data to travel and be interpreted consistently, while a patient-centered front end can make provenance, consent status, and longitudinal information visible. Yet a provenance indicator may increase trust when its meaning is clear, add burden when it is not, or be ignored when clinicians lack time to review externally generated information. The relevant unit of analysis is therefore the sociotechnical arrangement: the feature, the stakeholders expected to use or govern it, the workflow in which use occurs, and the authority and resources that make action possible.This framing also clarifies why care continuity should not be inferred from interoperability alone. Interoperability is a necessary capability, but continuity is an experienced and organizational outcome: relevant information is available at the right transition, interpreted in context, and used to coordinate a next step. Evaluation should trace that full pathway rather than stop at successful exchange. It should also examine the collective work through which PHDS use becomes routine: how participants make sense of the data space, enroll others in using it, perform the required tasks, and appraise its value over time (8). These processes may explain why the same technical capability becomes embedded in one setting but remains peripheral in another.SPHERE's contribution is to connect enabling structures with the work required to make them effective and accountable (4). Adapted cautiously, its components suggest four linked commitments for PHDS initiatives.First, align foundations and infrastructure. Legal authority, governance, financing, technical architecture, stewardship roles, and clinical accountability should be specified together. A right to access or control data has limited operational value if organizations are not responsible for ingesting, reconciling, and acting on authorized information. Conversely, an elegant architecture will remain fragile if consent, liability, secondary use, and cross-organizational responsibilities are unsettled. World Health Organization guidance likewise positions digital health as requiring coordinated governance, organizational capacity, and person-centered design, not technology in isolation (9).Second, co-produce the implementation system across stakeholder groups with distinct interests and forms of authority. Patients and caregivers have particular standing because the data concern identifiable persons and because PHDS choices can directly affect their autonomy, privacy, and care. However, healthcare professionals and provider organizations, payers and purchasers, researchers and public-health bodies, regulators and data stewards, and technology developers also create, use, finance, govern, or derive value from PHDSs. Their priorities may diverge: granular patient control can complicate clinical access; data availability for research can conflict with preferences concerning secondary use; documentation requirements can strengthen accountability while increasing workload; and short-term affordability decisions can constrain longer-term public benefit. A SPHERE-informed approach does not erase these tensions. It uses co-production to identify them, governance to clarify decision rights and accountability, and stakeholder-specific measures to examine how benefits, costs, risks, and work are distributed. Co-production should therefore encompass the surrounding service and governance pathway (not only the user interface) and should continue as evidence and conditions change (10).Third, specify strategies and measure implementation outcomes. Training, workflow redesign, facilitation, technical assistance, audit and feedback, and outreach are distinct strategies, not an undifferentiated implementation package. Each should be described by its actor, action, target, timing, dose, intended outcome, and rationale (11); established strategy compilations can support consistent naming while still requiring selection for local barriers (12). Early outcomes should include acceptability, adoption, appropriateness, feasibility, fidelity, cost, penetration, and sustainability (13), alongside population-specific reach and burden. These measures help distinguish a weak intervention from a strong intervention that is poorly implemented. They also prevent login counts or consent completion from standing in for meaningful use.Fourth, build feedback loops that connect implementation to continuity. PHDS initiatives should monitor not only system performance and security events, but also whether exchanged information changes care. Signals should include whether relevant data were available and reconciled, whether patients understood subsequent plans, whether duplicated work was avoided, and whether follow-up occurred. Quantitative patterns should trigger inquiry with users, nonusers, and other affected stakeholders; findings should then inform changes to interfaces, workflows, supports, governance, and implementation strategies. As Figure 1 illustrates, this is a recursive rather than linear process. Changes in legal requirements, medical knowledge, data availability, organizational relationships, or technology may require reconsideration of earlier assumptions and design choices. Responsive evaluation thus makes measurement part of governing and improving the system rather than a retrospective verdict and moves PHDSs toward a learning health system (14).Patient agency is central to PHDSs, but agency should not be reduced to the availability of settings, dashboards, or consent choices. Lin et al.'s dynamic consent framework appropriately treats consent as revisable rather than a one-time transaction and foregrounds traceability, withdrawal, and accountability (2). Its broader implementation implication is that control must be usable over time. People need to understand what a choice governs, anticipate its consequences, revisit it without undue burden, and obtain support when preferences or circumstances change. Supported agency should therefore be examined throughout design, implementation, and evaluation rather than treated solely as a property of the interface.Ruan et al.'s findings caution against designing for an abstract, self-sufficient user (3). Although their cross-sectional study did not evaluate PHDSs or establish causal mechanisms, its associations of active health behavior with health literacy, self-efficacy, social support, and material circumstances underscore that information availability does not ensure capacity to act. PHDS implementation should provide multiple routes to agency, including accessible interfaces, supported decision-making, safeguarded proxy access, assistance through clinical or community touchpoints, and non-digital alternatives where needed.Supported agency is also a health equity concern. Uniform access to a complex interface can reproduce health inequity when connectivity, language access, disability accommodations, institutional trust, time, or social support differ. Evaluations should therefore disaggregate reach, use, burden, and continuity outcomes and examine which groups are missing, withdrawing, delegating access, or experiencing unresolved data problems (15)(16)(17). Patient control is meaningful only when the practical conditions for exercising it are present.A PHDS evidence agenda should make five interrelated measurement dimensions explicit. First, technical performance measures (such as exchange success, semantic concordance, latency, provenance completeness, and security) show whether the infrastructure functions. Second, implementation measures assess whether people and organizations can and do use it. Third, mechanism-focused measures examine whether use changes comprehension, trust, supported agency, shared situational awareness, or coordination. Fourth, service and health outcomes test whether those changes improve continuity, timeliness, safety, experience, and health. Fifth, economic measures assess financial costs and the work or burden shifted among patients, caregivers, clinicians, organizations, payers, and other stakeholders. Findings in one dimension should be interpreted in relation to the others: technically successful exchange, for example, cannot establish benefit if the information is not incorporated into work or if doing so produces unsustainable burden.No single study must cover the entire chain, but programs should identify which links they are testing and avoid claims that cross unmeasured links. Dynamic consent may strengthen perceived control and trust, but these mechanisms and their downstream effects require prospective study (2). Semantic integration may improve information availability, while its usability and workflow fit require evaluation in practice (1). Mixed methods, pragmatic trials, longitudinal implementation studies, and comparative case studies can collectively establish what works, for whom, under which conditions, and at what cost. RE-AIM can additionally examine whether benefits extend across intended populations and settings and endure over time (18).Several frameworks could support PHDS implementation, and SPHERE should not be presented as uniquely capable of doing so. NASSS offers a technology-specific account of complexity across the condition, technology, value proposition, adopter system, organizations, wider context, and adaptation over time (6). CFIR provides a more detailed taxonomy of multilevel implementation determinants (5), SEIPS foregrounds interactions within work systems (7), and RE-AIM organizes population-and setting-level impact (18). The CeHRes Roadmap 2.0 more directly guides the intertwined development, implementation, and evaluation of eHealth technologies through continuous stakeholder involvement and formative evaluation (19). A recent review further found that NASSS has been used most often retrospectively and called for greater prospective and concurrent application during implementation (20).SPHERE's complementary contribution is its explicit connection of enabling foundations and infrastructure with co-production, implementation strategies, process and mechanism measures, outcomes, equity, and responsive feedback (4). This structure helps connect the five practical questions posed here (who benefits, what work is required, which strategies support that work, which mechanisms connect use to continuity, and what evidence should trigger revision) to specific parts of an implementation logic rather than treating them as a stand-alone checklist. Its limitations are equally important. SPHERE was developed for policies enabling social prescribing, has not been prospectively validated for PHDS implementation, and provides less technological and work-system detail than NASSS, CeHRes, or SEIPS. It is therefore best used as an orienting scaffold alongside, rather than in place of, frameworks selected for particular analytic tasks.For PHDS initiatives, the practical implication is to design implementation and evaluation with the data space and to revisit both over time.