- Consent based healthcare data export review
- What the literature says at a glance
- Core technical stack
- Consent models and governance
- Implementation patterns that recur across the literature
- Consumer mediated exchange and patient trust
- Prior authorization as a product wedge
- Product architecture implied by the evidence
- Where the literature is mature and where it is thin
- Strategic conclusions for a product thesis
- References
Consent based export of healthcare data has moved from a policy aspiration to an implementable product surface. The strongest part of the evidence base sits where four lines of work meet: SMART on FHIR as the authorization and app platform [Man16b], Bulk FHIR and EHI export as the scalable extraction layer [Man20, Phe24, Jon21], computable consent models built on FHIR and related profiles [Bil20, Bia22, Bia18, Lac18], and privacy preserving segmentation for sensitive records [Lee24, Sar23, Rot19]. The literature does not support a simple view in which consent is a single checkbox placed in front of a data API. Instead, it points to a layered product problem that combines identity, authorization, consent capture, policy translation, segmentation, audit, and governance [Hei11, Ver21, Mil24b].
For product strategy, the clearest conclusion is that the winning design is not a monolithic consent registry. It is a consent aware exchange layer that can sit across patient facing export, provider to provider exchange, and payer workflows, while translating legal and organizational rules into computable decisions at the point of data release [Bil20, Bia22, Phe24, Man22]. Prior authorization is relevant, but mainly as a downstream workflow where consent, provenance, and standard payload exchange matter. The prior authorization literature is more mature on workflow pain and standards direction than on proven end to end FHIR native products [Joh22, Bra22, Gon16, Shr20].
| Product question | Strongest answer from the literature | Key papers | Product meaning |
|---|---|---|---|
| How should apps gain access to EHR data | SMART on FHIR is the dominant reusable app and authorization pattern | [Man16b, Blo17, Nei20] | Build around standards based OAuth style app authorization rather than bespoke interfaces |
| How should full record export work | Bulk FHIR and EHI export provide the scalable path beyond portal downloads | [Man20, Jon21, Phe24] | Separate single patient app access from asynchronous export workflows |
| Can consent be represented in interoperable form | Yes, but native models often need profiles, code systems, and mapping layers | [Bil20, Bia22, Bia18, Lac18] | Product needs a policy translation layer, not just a database table for consent |
| Can patients control sensitive subsets of records | Partly. Granular segmentation is feasible but terminology and implementation remain immature | [Lee24, Sar23, Rot19, Col14] | Sensitive data controls should be treated as a first class feature, not an edge case |
| Does policy mainly block exchange | Less than often claimed. The larger problems are variation, incentives, workflow burden, and trust | [Mel18, Hol23, Apa20] | Compliance alone will not create adoption |
| Is patient mediated sharing viable | Yes, and policy increasingly supports it, but trust and app governance remain weak points | [Moh15, Dul24, Sav20b, Say20] | Product needs visible trust, app disclosure, and user level auditability |
| Is prior authorization a good proving ground | Yes for structured exchange and status tracking, but evidence for mature FHIR native deployments is still limited | [Joh22, Bra22, Gon16, Shr20] | Good wedge use case if paired with broader export and consent infrastructure |
SMART on FHIR established the basic pattern for substitutable apps that can run across health IT systems using common web standards, standard medical terminologies, and a shared clinical API model [Man16b]. That matters product wise because it reduces dependence on one EHR vendor and shifts differentiation away from point integrations and toward workflow, policy, and user experience. Real world deployment work shows that patient facing APIs were often activated because of policy pressure and platform shifts such as smartphone health record features, but health systems still reported immature standards, weak app ecosystems, security concerns, and uneven business incentives [Nei20, Dul20].
A useful product reading of this literature is that API access is necessary but not sufficient. Products that stop at connectivity inherit the same adoption ceiling seen in early patient API rollouts. The evidence suggests that value comes from pairing standardized access with a clearer use case such as longitudinal record assembly, delegated sharing, release control, or payer transaction automation [Nei20, Dul24].
The strongest modern export literature centers on Bulk FHIR and the EHI export concept. Bulk FHIR was designed to standardize extraction of patient level data across entire populations, initially for research, public health, and analytics [Man20]. Survey work soon after showed broad implementation interest not only among regulated actors but also among research, cloud, public health, and payer organizations, suggesting the standard had become a platform for secondary ecosystems rather than a narrow compliance feature [Jon21].
The most product relevant paper in the set is the reference implementation for a patient controlled EHI export API [Phe24]. Its model is explicitly asynchronous and app driven. Patients request export, an EHI server fulfills the request, and an administrative layer manages workflow and exceptions [Phe24]. That architecture is important because it separates two kinds of access that are often conflated:
- interactive API access for apps and portals
- asynchronous release of a complete record set
Products that treat these as the same workflow tend to underbuild export management. The literature supports an export service with request lifecycle handling, status, packaging, provenance, and downstream share controls [Phe24, Jon21].
FHIR provides a Consent resource, but the evidence repeatedly shows that raw standards are not enough for production interoperability. Work from the German Medical Informatics Initiative found that multiple institutions needed a common digital representation of consent status, validity period, and modular permissions that could be mapped across HL7 FHIR, IHE BPPC, and the gICS consent system [Bil20]. The practical lesson is that product teams should expect to maintain a canonical internal policy model and map it outward, rather than assume one external standard will perfectly encode the business and legal reality.
The gICS papers strengthen this point. Early work proposed import and export functions for reusable modular consent templates using FHIR [Bia18]. Later work showed a nationwide exchange of consent information across German university hospitals through a FHIR compliant gateway and preconfigured broad consent templates [Bia22]. This is one of the most concrete demonstrations in the set that computable consent exchange can work at network scale when profiles, templates, and implementation guidance are tightly aligned [Bia22].
The treatment eConsent model based on HL7 FHIR reaches a similar conclusion from a different angle. It showed that core FHIR structures can support electronic treatment consent, but only with added resources for patient communication and custom extensions where standard maturity is insufficient [Lac18]. In product terms, consent capture and consent enforcement should be modeled as separate concerns:
- consent capture needs clear content, user comprehension, versioning, and withdrawal support [Lac18, Ver21]
- consent enforcement needs computable policies, recipient context, time validity, and release decisions [Bil20, Hei11, Mil24b]
A major weakness in many data export products is the assumption that the record is either fully released or fully blocked. The segmentation literature rejects that binary model. The modern FHIR based segmentation work used FHIR R5 Consent, CDS Hooks, and sensitivity labeling to support patient choices about sharing categories such as substance use information [Lee24]. It explicitly moved beyond older binary classifications toward configurable confidence thresholds and more realistic clinical categorization [Lee24].
The broader literature frames segmentation as an equity and trust issue as much as a privacy feature. Adolescents and people with behavioral health or substance use records can be harmed by crude release models that expose data too broadly or by overblocking that breaks continuity of care [Sar23, Pet24b]. Legal and ethics commentary argues that segmentation is one of the few practical ways to reconcile expanding interoperability with confidentiality duties for specially protected information [Rot19, Mel18].
For products, this means granular controls are not polish. They are part of the core architecture. A credible platform needs at least four segmentation primitives:
- data type sensitivity labels
- recipient aware policies
- purpose aware release rules
- redaction or transform services before export
The pilot evidence on patient preferences supports this direction. Patients in behavioral health settings strongly preferred granular control, and willingness to share increased when data type, recipient, and purpose could be specified [Kar22].
The older policy literature remains useful because it names the design space clearly. Consent for exchange can be organized around no consent, opt out, opt out with exceptions, opt in, and opt in with restrictions, with wide variation in granularity and scope [Gol10b]. That taxonomy still maps well to modern product choices. The important lesson is that the consent model is not merely a policy variable. It changes enrollment friction, support burden, missing data risk, and release complexity [Gol10b, Apa20].
US evidence suggests opt in regimes create more administrative burden, especially for organizations with weaker technical maturity [Apa20]. At the same time, the legal review literature argues that privacy law is often blamed for exchange failures that are in fact driven by incentives, competition, and organizational risk aversion [Mel18]. Together these findings suggest a product principle: reduce the operational cost of stricter consent choices rather than assuming the market will converge on simpler defaults.
A second governance theme is that patient directed sharing is increasingly well supported in law and policy, but governance weakens when data leaves a covered entity and enters a consumer app. HIPAA generally permits patient directed electronic transmission to third party apps [Sav20b]. Yet the protections over those apps may shift from health privacy law to broader consumer protection law, creating a trust gap that product design must bridge with disclosures, transparency, and audit tools [Say20].
| Pattern | Why it appears repeatedly | Evidence |
|---|---|---|
| Canonical internal policy model with outward mappings | External standards and local legal text do not align perfectly | [Bil20, Bia18, Lac18] |
| Separate consent capture from access control enforcement | User comprehension and machine execution require different models | [Lac18, Hei11, Ver21] |
| Asynchronous export workflow | Full record release is operationally different from app reads | [Phe24, Man20] |
| Central policy decision and audit services | Exchange participants need a consistent answer at release time | [Hei11, Bia22, Mil24b] |
| Sensitive data labeling and redaction layer | Special categories cannot be handled safely by all or nothing release | [Lee24, Col14, Rot19] |
| Human readable app disclosure and governance | Patients need to understand downstream use once data leaves the EHR | [Say20, Dul24] |
| Template and profile driven rollout | Network scale deployment depends on constrained implementation guidance | [Bia22, Jon21] |
The consumer mediated exchange literature shows a long arc from Blue Button downloads to app based API ecosystems. Blue Button demonstrated that simple patient facing export could drive engagement and normalize the idea that records can be downloaded and moved by the patient [Moh15]. More recent reviews show that the field has expanded toward cross stakeholder exchange, richer standards, and more patient centered sharing models [Dul24].
But the trust problem has also become sharper. Patient facing API deployments reported concern about security, weak app quality, and limited business drivers [Nei20]. Legal analysis of consumer directed sharing noted that the act of sending data to a third party app is broadly permissible, yet downstream oversight may be thinner than patients assume [Sav20b, Say20]. Research focused on consumer mediated exchange for research adds that organizations themselves may distrust these pathways even when the law allows them, because provenance, duty allocation, and app governance remain unsettled [Bra19c].
A product that ignores this trust layer will struggle even if the API layer is strong. The literature points toward three practical trust mechanisms:
- pre transfer disclosure of app data practices in a standardized form [Say20]
- user visible logs showing when, what, and to whom data were released [Man22, Ver21]
- controls for revocation, expiration, and scope reduction that remain intelligible to patients [Bil20, Kar22]
Prior authorization appears in this literature for good reason. It is a high pain workflow where provider and payer systems need structured exchange, status visibility, and less manual rework. The evidence base, however, is uneven.
The strategic literature argues that prior authorization should move into the EHR using evidence based and computable workflows rather than remain a largely manual transaction [Joh22]. FHIR oriented overviews of payment workflows show why the use case is attractive for standards based products, since prior authorization depends on consistent representation of orders, documentation, coverage context, and payer decisions [Bra22, Bra18]. Earlier implementation work from Colombia proposed an HL7 FHIR based interoperability framework for service authorization, including patient status visibility through web and mobile tools [Gon16]. Review pieces on electronic prior authorization describe the field as active but still fragmented [Shr20].
The key product insight is that prior authorization is not a separate market from consent based export. It is a constrained version of the same problem:
- identify what data package is needed
- justify why it can be shared
- transmit it in a standard form
- track status and decisions
- preserve provenance and auditability
Where prior authorization differs is in the stronger role of payer rules, event driven updates, and decision support. That makes it a useful wedge if the underlying platform already knows how to package records, enforce policy, and manage asynchronous exchange. It is a weaker wedge if the product has only forms automation and no interoperable release engine.
| Layer | Minimum capability | Why the literature supports it | Key papers |
|---|---|---|---|
| Identity and authorization | SMART on FHIR compatible app authorization and actor authentication | Reusable access across systems starts here | [Man16b, Nei20] |
| Export orchestration | Request, queue, fulfill, status, retry, packaging | Full EHI export is asynchronous and operationally heavy | [Phe24, Man20] |
| Consent registry | Versioning, scope, validity, withdrawal, provenance | Consent is longitudinal and modular, not a one time flag | [Bil20, Bia22, Ver21] |
| Policy engine | Translate law and local rules into release decisions | Standards alone do not encode actual permissions | [Hei11, Mil24b, Bil20] |
| Segmentation service | Label, filter, redact, transform sensitive content | Granular privacy is needed for safety and equity | [Lee24, Sar23, Rot19] |
| Audit and transparency | End user logs, organization logs, recipient logs | Trust and patient control require visibility | [Man22, Ver21] |
| Governance surface | App disclosure, recipient trust signals, policy review tools | Legal permission is not enough for user trust | [Say20, Dul24, Bra19c] |
| Workflow adapters | EHR, HIE, payer, portal, research endpoints | Exchange succeeds when embedded in real workflows | [Bia22, Joh22, Gon16] |
- standards based app access through SMART on FHIR [Man16b]
- population and export oriented FHIR extraction [Man20, Jon21, Phe24]
- structured consent representation and mappings across profiles [Bil20, Bia22, Bia18]
- recognition that segmentation of sensitive data is essential [Lee24, Sar23, Rot19]
- evidence that law is only one part of the exchange barrier picture [Mel18, Hol23, Apa20]
- broad real world evidence on patient adoption of granular consent tools beyond pilots [Kar22]
- mature write back and bidirectional workflows in patient facing API ecosystems [Dul20]
- standardized trust and disclosure mechanisms for consumer apps after data leaves HIPAA covered entities [Say20]
- production scale evidence for FHIR native prior authorization products across many payers and EHRs [Joh22, Gon16, Shr20]
- cross jurisdiction operational models that combine export, consent, and segmentation without heavy local tailoring [Bin20, Sch20, Raa23]
The literature supports a product thesis built around consent aware export infrastructure rather than around static consent forms. The hardest problem is not getting data out of an EHR once. It is making release decisions repeatable, explainable, and trustworthy across many recipients and use cases [Bil20, Ver21, Lee24].
A strong product in this space would combine five differentiators that are rarely present together in the current literature:
- patient controlled export requests for complete EHI and selected subsets [Phe24, Kar22]
- computable consent that can be exchanged across organizations rather than trapped inside one site [Bia22, Bil20]
- sensitive data segmentation that goes beyond binary block or release [Lee24, Sar23]
- transparent app and recipient governance for data leaving covered entities [Say20, Sav20b]
- reusable workflow adapters for payer and provider transactions such as prior authorization [Joh22, Bra22, Gon16]
The evidence also suggests a sequencing logic. The most defensible entry point is a narrow but high value workflow where release rights, payload composition, and audit matter every time. Prior authorization fits that pattern, but only if it is treated as a first use case for a general release engine rather than as a standalone automation tool [Joh22, Shr20]. A second viable entry point is patient directed full record export where policy momentum and standards readiness are strongest [Phe24, Man20, Dul24].
The central risk is overestimating standard maturity. FHIR, SMART, and related profiles provide the grammar of exchange, but they do not remove the need for local mappings, profile constraints, governance, and operational tooling [Lac18, Bil20, Nei20]. The literature consistently rewards products that treat standards as a base layer and invest the real differentiation in policy execution, segmentation, workflow fit, and trust design [Bia22, Lee24, Say20].
[Man16b] J. C. Mandel, D. A. Kreda, K. Mandl, I. Kohane, and R. Ramoni, “SMART on FHIR: a standards-based, interoperable apps platform for electronic health records,” Journal of the American Medical Informatics Association : JAMIA, vol. 23, pp. 899–908, Feb. 2016, doi: 10.1093/jamia/ocv189.
[Man20] K. Mandl et al., “Push Button Population Health: The SMART/HL7 FHIR Bulk Data Access Application Programming Interface,” NPJ Digital Medicine, vol. 3, Nov. 2020, doi: 10.1038/s41746-020-00358-4.
[Phe24] D. Phelan et al., “Beyond compliance with the 21st Century Cures Act Rule: a patient controlled electronic health information export application programming interface,” Journal of the American Medical Informatics Association : JAMIA, vol. 31, pp. 901–909, Jan. 2024, doi: 10.1093/jamia/ocae013.
[Jon21] J. Jones et al., “A landscape survey of planned SMART/HL7 bulk FHIR data access API implementations and tools,” Journal of the American Medical Informatics Association : JAMIA, Mar. 2021, doi: 10.1093/jamia/ocab028.
[Bil20] R. Bild et al., “Towards a comprehensive and interoperable representation of consent-based data usage permissions in the German medical informatics initiative,” BMC Medical Informatics and Decision Making, vol. 20, Jun. 2020, doi: 10.1186/s12911-020-01138-6.
[Bia22] M. Bialke et al., “A FHIR has been lit on gICS: facilitating the standardised exchange of informed consent in a large network of university medicine,” BMC Medical Informatics and Decision Making, vol. 22, Dec. 2022, doi: 10.1186/s12911-022-02081-4.
[Bia18] M. Bialke et al., “MAGIC: once upon a time in consent management—a FHIR® tale,” Journal of Translational Medicine, vol. 16, Sep. 2018, doi: 10.1186/s12967-018-1631-3.
[Lac18] A. M. Lackerbauer, A. C. Lin, O. Krauss, J. Hearn, and E. Helm, “A Model for Implementing an Interoperable Electronic Consent Form for Medical Treatment Using HL7 FHIR,” 2018. doi: 10.24105/EJBI.2018.14.3.6.
[Lee24] P. Lee, D. Mendoza, M. Kaiser, E. Lott, G. Singh, and A. Grando, “FHIR Granular Sensitive Data Segmentation,” Applied Clinical Informatics, vol. 16, pp. 156–166, Aug. 2024, doi: 10.1055/a-2466-4371.
[Sar23] C. Sarabu, M. Sharko, C. Petersen, and H. K. Galvin, “Shifting into Action: from Data Segmentation to Equitable Interoperability for Adolescents (and Everyone Else),” Applied Clinical Informatics, vol. 14, pp. 544–554, Jan. 2023, doi: 10.1055/s-0043-1769924.
[Rot19] M. Rothstein and S. A. Tovino, “Privacy Risks of Interoperable Electronic Health Records: Segmentation of Sensitive Information Will Help,” The Journal of Law, Medicine & Ethics, vol. 47, pp. 771–777, Oct. 2019, doi: 10.1177/1073110519897791.
[Hei11] O. Heinze, M. Birkle, L. Köster, and B. Bergh, “Architecture of a consent management suite and integration into IHE-based regional health information networks,” BMC Medical Informatics and Decision Making, vol. 11, pp. 58–58, Oct. 2011, doi: 10.1186/1472-6947-11-58.
[Ver21] S. Verreydt, K. Yskout, and W. Joosen, “Security and Privacy Requirements for Electronic Consent,” ACM Transactions on Computing for Healthcare, vol. 2, pp. 1–24, Mar. 2021, doi: 10.1145/3433995.
[Mil24b] Z. Milosevic, “Consumer-Centered Consent Automation in Health Information Exchange.” Studies in health technology and informatics, vol. 318, pp. 132–137, Sep. 2024, doi: 10.3233/SHTI240904.
[Man22] J. C. Mandel, J. P. Pollak, and K. Mandl, “The Patient Role in a Federal National-Scale Health Information Exchange,” Journal of Medical Internet Research, vol. 24, Nov. 2022, doi: 10.2196/41750.
[Joh22] P. T. Johnson, B. Lau, S. J. Conway, L. Riley, and P. D. Hill, “Evidence-Based, Prior Authorization in the Electronic Health Record: A Better Path Forward.” Journal of the American College of Radiology : JACR, Mar. 2022, doi: 10.1016/j.jacr.2022.02.029.
[Bra22] M. Braunstein, “FHIR Applications in Payment,” 2022. doi: 10.1007/978-3-030-91563-6_6.
[Gon16] B. González and H. Duarte, “Interoperabilidad en el proceso de autorización de servicios de salud basado en HL7-FHIR,” Nov. 19, 2016.
[Shr20] T. Shryock and L. Lutton, “Electronic prior authorizations in healthcare today,” Jan. 28, 2020.
[Blo17] R. A. Bloomfield, F. Polo-Wood, J. C. Mandel, and K. Mandl, “Opening the Duke electronic health record to apps: Implementing SMART on FHIR,” International journal of medical informatics, vol. 99, pp. 1–10, Mar. 2017, doi: 10.1016/j.ijmedinf.2016.12.005.
[Nei20] A. B. Neinstein, C. Thao, M. Savage, and J. Adler-Milstein, “Deploying Patient-Facing Application Programming Interfaces: Thematic Analysis of Health System Experiences,” Journal of Medical Internet Research, vol. 22, Jan. 2020, doi: 10.2196/16813.
[Col14] J. Coleman, “Protecting High-Stakes PHI: DS4P Healthcare Standards Enhance the Privacy of Sensitive Data,” Apr. 01, 2014.
[Mel18] M. Mello, J. Adler-Milstein, K. L. Ding, and L. Savage, “Legal Barriers to the Growth of Health Information Exchange-Boulders or Pebbles?” The Milbank quarterly, vol. 96 1, pp. 110–143, Mar. 2018, doi: 10.1111/1468-0009.12313.
[Hol23] A. Holmgren, M. Esdar, J. Hüsers, and J. Coutinho-Almeida, “Health Information Exchange: Understanding the Policy Landscape and Future of Data Interoperability,” Yearbook of Medical Informatics, vol. 32, pp. 184–194, Jul. 2023, doi: 10.1055/s-0043-1768719.
[Apa20] N. C. Apathy and J. Holmgren, “Opt-in consent policies: potential barriers to hospital health information exchange.” The American journal of managed care, vol. 26 1, pp. e14–e20, Jan. 2020, doi: 10.37765/ajmc.2020.42148.
[Moh15] M. O. Mohsen and H. A. Aziz, “The Blue Button Project: Engaging Patients in Healthcare by a Click of a Button.” Perspectives in health information management, vol. 12, pp. 1d, Apr. 2015.
[Dul24] P. Dullabh, R. V. Dhopeshwarkar, and P. Desai, “New Horizons for Consumer-Mediated Health Information Exchange,” Yearbook of Medical Informatics, vol. 33, pp. 179–190, Aug. 2024, doi: 10.1055/s-0044-1800741.
[Sav20b] M. Savage and L. Savage, “Doctors Routinely Share Health Data Electronically Under HIPAA, and Sharing With Patients and Patients’ Third-Party Health Apps is Consistent: Interoperability and Privacy Analysis,” Journal of Medical Internet Research, vol. 22, Sep. 2020, doi: 10.2196/19818.
[Say20] R. Sayeed, J. Jones, D. Gottlieb, J. C. Mandel, and K. Mandl, “A proposal for shoring up Federal Trade Commission protections for electronic health record–connected consumer apps under 21st Century Cures,” Journal of the American Medical Informatics Association : JAMIA, vol. 28, pp. 640–645, Dec. 2020, doi: 10.1093/jamia/ocaa227.
[Dul20] P. Dullabh, L. Hovey, K. Heaney-Huls, N. Rajendran, A. Wright, and D. F. Sittig, “Application Programming Interfaces in Health Care: Findings from a Current-State Sociotechnical Assessment,” Applied Clinical Informatics, vol. 11, pp. 59–69, Jan. 2020, doi: 10.1055/s-0039-1701001.
[Pet24b] C. Petersen, H. K. Galvin, C. Lehmann, and M. Sharko, “Equitable Interoperability Through Precise Control of Sensitive Health Information: An Emerging Pathway to Health Equity,” Annals of Internal Medicine, vol. 177, pp. 387–388, Mar. 2024, doi: 10.7326/M23-2876.
[Kar22] G. Karway et al., “My Data Choices: Pilot evaluation of patient-controlled medical record sharing technology,” Health Informatics Journal, vol. 28, Oct. 2022, doi: 10.1177/14604582221143893.
[Gol10b] M. Goldstein and A. Rein, “Consumer Consent Options for Electronic Health Information Exchange: Policy Considerations and Analysis,” 2010.
[Bra19c] Y. Bracha, J. Bagwell, R. Furberg, and J. Wald, “Consumer-Mediated Data Exchange for Research: Current State of US Law, Technology, and Trust,” JMIR Medical Informatics, vol. 7, Jun. 2019, doi: 10.2196/12348.
[Bra18] M. Braunstein, “Payer Applications of FHIR,” 2018. doi: 10.1007/978-3-319-93414-3_6.
[Bin20] G. Bincoletto, “Data protection issues in cross-border interoperability of Electronic Health Record systems within the European Union,” Mar. 30, 2020. doi: 10.1017/dap.2020.2.
[Sch20] J. Scheibner et al., “Data protection and ethics requirements for multisite research with health data: a comparative examination of legislative governance frameworks and the role of data protection technologies†,” Journal of Law and the Biosciences, vol. 7, Jan. 2020, doi: 10.1093/jlb/lsaa010.
[Raa23] R. Raab et al., “Federated electronic health records for the European Health Data Space.” The Lancet. Digital health, Sep. 2023, doi: 10.1016/s2589-7500(23)00156-5.