The individual is a primary stakeholder. All systems, regulations, and network designs must support the individual's right to easily access, understand, correct, control, and use their complete health data, free of charge.
All authorized users and their designated tools and applications must have pervasive, timely, and efficient access to both standardized data (e.g., USCDI via individual and bulk FHIR APIs) and to complete, computable Electronic Health Information (EHI via API) as a foundational backstop. Usability and performance of these access methods are paramount.
The ecosystem must actively support innovation from all sources, including individual patients developing or choosing their own tools to access and manage their own data. Barriers to entry for good-faith individual participation must be eliminated, ensuring pathways that do not require commercial-grade registration for individuals developing tools and applications for their own use. Our data access frameworks must anticipate and support the rapidly growing ability for individuals to "scratch their own itch," especially as current and near-future AI enables new forms of personal tool development.
National-scale exchange frameworks like TEFCA, and their participating entities (like QHINs and health systems), must evolve under federal guidance to ensure individual transparency (e.g., clear pathways for individuals to access network audit logs revealing usage of their own data) and granular control (e.g., consent, opt-out). The Federal government should actively steer TEFCA's evolution to incorporate these as core, non-negotiable design tenets.
To foster a competitive and innovative health IT market, foundational infrastructure and access pathways must be established on fair and open terms. This includes:
Recommendation: ONC must lead an improved, evidence-based USCDI development and adoption process to ensure that an expanding set of meaningfully standardized and clinically relevant patient data elements is defined. This enhanced USCDI will serve as the common data foundation for all mandated FHIR-based APIs.
Rationale & Specifics:
Recommendation: The ONC Health IT Certification Program must ensure certified Health IT systems implement current, stable, industry-adopted versions of the SMART App Launch Framework and related backend services specifications to support secure and functional single-patient FHIR API access.
Rationale & Specifics: To enable a broad ecosystem of secure and innovative single-patient applications:
offline_access Scope: Ensure the offline_access scope is available for consumer approval for any registered app type (public, confidential, native, browser-based) to empower applications with persistent access and improve user experience. Certification must validate correct and complete implementation.Recommendation: The ONC Health IT Certification Program must ensure certified Health IT systems implement current, stable, industry-adopted versions of the FHIR Bulk Data Access (Flat FHIR) specification to support efficient, population-level export of USCDI data.
Rationale & Specifics: To enable scalable population health, research, and system transition use cases:
_since for incremental updates and _typeFilter (or equivalent mechanisms) for granular data scoping of exported resources. Certification must validate correct implementation. Incremental updates enable systems to use efficient bulk exports that only contain required data and can be processed rapidly. In contrast to notifications when there are changes, incremental export requests represent a simpler approach to integration, support export of historical data, and do not require both the data provider system and the data consumer system to be continuously online. Recommendation: Certified Health IT implementing FHIR Bulk Data APIs must be foundationally designed to operate efficiently at the population level, and their performance in exporting USCDI data must achieve parity with any proprietary bulk export mechanisms offered by the same system.
Rationale & Specifics: To ensure the regulated Bulk FHIR API is a viable and primary mechanism for population data export, rather than a secondary, underperforming option:
Recommendation:
Rationale & Specifics: A complete, computable, and API-accessible export of all EHI is a cornerstone of patient data access rights and enables numerous use cases, from personal health record aggregation to data migration and advanced analytics by patient-chosen tools.
patient/$ehi-export scope) for patient-facing app authorization, as defined in the Argonaut EHI Export API IG.ehiDocumentationUrl) necessary for interpreting the contents of the export, as specified in the Argonaut IG.Link header with rel="patient-interaction" to direct the user to a page for specifying these options.ehiDocumentationUrl in the manifest.By aligning with industry-developed specifications like the Argonaut EHI Export API IG, ONC can ensure a more consistent, interoperable, and functional approach to fulfilling the Cures Act requirement for full EHI export, making it truly useful for patients and the applications they authorize.
Recommendation: Certified Health IT must provide a clear, easily discoverable, and entirely electronic self-service mechanism for patients to request their complete Electronic Health Information (EHI). This functionality must allow patients to initiate and track their EHI export requests without resorting to manual processes such as phone calls, paper forms, or faxes.
Rationale & Specifics: Patients have a right to access their EHI without undue burden. Current manual request processes are often slow, opaque, and frustrating for patients, creating significant barriers to accessing their own health information. A self-service electronic mechanism is a fundamental step towards empowering patients.
Recommendation: Certified Health IT must support secure, patient-initiated messaging to healthcare providers from third-party applications, utilizing standardized APIs. Signal intent to adopt community-developed standards such as the Argonaut Project's Provider/Patient Secure Messaging API Implementation Guide (https://hackmd.io/@argonaut/H1dQ95xG3) via SVAP.
Rationale & Specifics: To improve patient engagement and streamline communication within the healthcare system:
Recommendation: Certified Health IT must provide clear, secure, and entirely electronic pathways for individuals to request amendments to their medical records, track the status of these requests, and receive responses, thereby making HIPAA-granted rights more accessible and usable. These pathways must be available through patient-facing interfaces (e.g., patient portals) and programmatically via APIs for patient-authorized applications.
Rationale & Specifics: Making the HIPAA right to request record amendments electronically functional is crucial for data accuracy, patient trust, and engagement. Current manual processes are often burdensome. This could be combined with the approach for "Mandate Patient-Initiated Secure Messaging via Standardized APIs".
This ensures patients can exercise their amendment rights efficiently through modern electronic means, contributing to better data quality and patient empowerment.
Recommendation: Certified Health IT must implement support for a defined starter set of FHIR Subscription topics to enable event-driven data synchronization and application workflows, reducing inefficient polling and supporting timely notifications. Rationale & Specifics: Real-time awareness of data changes is crucial for many clinical and patient-facing applications.
Recommendation: Certified Health IT must support the CDS Hooks specification as a standardized method for integrating external clinical decision support (CDS) services directly into EHR workflows. Rationale & Specifics: Integrating evidence-based guidance and advanced analytics at the point of care requires a standard interface.
patient-view hook for context-aware information display and potentially order-sign or order-select for interventional CDS).fhirAuthorization access tokens to allow CDS services to securely access necessary patient data via FHIR APIs.Recommendation: Certified Health IT must provide programmatic and automatable API access to diagnostic quality medical images, using consistent, standardized authorization flows and ensuring images are shareable and usable by authorized applications. Rationale & Specifics: Medical images are critical clinical data, yet their accessibility via APIs has lagged. EHRs could certify to these capabilities by integrating with an underlying Picture Archiving and Communication System (PACS) as long as all the configuration was in place to make the user and app experience seamless; EHRs are not required to directly store and manage detailed study metadata and raw imaging data, as long as they allow seamless access alongside other clinical data.
Recommendation: To ensure patients can establish patient portal accounts securely and conveniently online:
Rationale & Specifics: The fundamental goal is to make secure, online patient portal account creation a standard, accessible option for all patients. This requires a two-pronged approach: CEHRT must provide the necessary robust technical capabilities, and healthcare providers must make these capabilities available to patients as part of their participation in federal healthcare programs.
Recommendation: ONC must ensure, through proactive engagement with the RCE and evolution of the TEFCA Common Agreement, Qualified Health Information Network Technical Framework (QTF), and associated Standard Operating Procedures (SOPs), that individuals have visibility into and control over how their data is exchanged under TEFCA. Individuals must have robust mechanisms to review audit logs and manage data sharing, accessible through TEFCA-designated services that ensure their choices are honored by all TEFCA QHINs and Participants.
Rationale & Specifics: Building public trust in TEFCA requires empowering individuals with direct oversight and control. The TEFCA framework, its participating QHINs, and connected Health IT systems must support the following:
TEFCA-level Patient Sharing Controls and Notifications via Discoverable Interfaces:
Patient-Accessible TEFCA Audit Logs:
Certified Health IT Support for Honoring TEFCA Patient Sharing Choices and Enabling TEFCA Audit Log Access:
Recommendation: ONC, in coordination with the RCE, must define, oversee, and mandate support for a "TEFCA Patient-Developer Credential." This program will provide individuals with a unique, identity-bound digital credential. This credential will enable applications they develop and directly control to securely access only their own data via all standard TEFCA QHIN APIs, and to facilitate simplified registration and access directly with participant EHR FHIR API endpoints, free of network or prohibitive registration access charges for this specific personal use.
Rationale & Specifics: To fully empower individuals, foster grassroots innovation, and ensure patients can directly participate in managing their health information, a dedicated and comprehensive pathway is needed. This pathway allows individuals, acting as their own developers, to bypass commercial IAS provider intermediaries for TEFCA network access and simplifies direct connection to EHRs for their personal data. It positions the patient as a direct, albeit limited-scope, participant across the ecosystem for their own information.
req_tefca_trustworthy_ias_architecture).Recommendation: The TEFCA Common Agreement and QTF must mandate a high-assurance security and authorization architecture for all Individual Access Services (whether commercial IAS providers or services facilitating the Patient-Developer Credential). This architecture must ensure that applications accessing data on behalf of an individual do so based on explicit, verifiable individual consent, mediated by a narrow set of trusted identity and authorization service providers, with verifiable binding between identity and authorization.
Rationale & Specifics: Protecting patient data shared via any individual access pathway within TEFCA requires a robust, standardized architecture that clearly separates roles and ensures accountability. This model prevents applications from self-attesting permissions and helps limit the potential impact of a compromised application.
All Individual Access Service pathways, including those used by commercial providers and those facilitating the Patient-Developer Credential, must rely on a defined, limited set of federally recognized or TEFCA-approved, high-assurance Identity Providers (IdPs) for initial individual identity verification. This establishes a "narrow waist" for trusted identity proofing.
The act of an individual authorizing an application to access their data must be a distinct, explicit step mediated by a trusted authorization service that leverages the verified identity from an approved IdP. The resulting authorization artifact (e.g., a SMART on FHIR authorization code exchanged for an access token, a FHIR Consent resource, or other digitally signed permission) must be cryptographically bound to the verified individual identity and the specific application being authorized, ensuring non-repudiation and that permissions are granted by the legitimate data subject to a specific recipient for defined purposes.
Critical Architecture Constraints:
Applications, upon presenting a valid, identity-bound authorization credential, are granted access only to the data permitted by that specific authorization. This principle, combined with fine-grained consent capabilities, helps limit the "blast radius" of any single compromised application or token. Repeated user authentication should not be needed in the context of an ongoing authorization providing long-term network-based access in TEFCA.
Within this trustworthy and flexible framework, QHINs must provide or ensure individuals have access to functionalities enabling them to:
Recommendation: ONC should lead or actively support the establishment, maintenance, and governance of publicly available, free, and machine-readable national directory services crucial for enabling nationwide health information exchange and interoperability. Rationale & Specifics: Effective, scalable interoperability across a diverse national landscape requires common, trusted, and easily accessible infrastructure for discovering participants, their capabilities, and their electronic endpoints. This reduces friction for all stakeholders, from application developers to HINs and individual patients seeking to connect.