Author: Administrator

By JOSHUA MANDEL, MD, DAN GOTTLIEB, MPA, and KENNETH D. MANDL, MD, MPH

We strongly support ASTP/ONC’s objective of expanding standards-based, API-driven interoperability to include diagnostic imaging. The market today is highly fragmented, relying on physical media and proprietary viewer portals that are not accessible via standards-based APIs. However, the technical building blocks to solve this — SMART on FHIR, DICOMweb, and OAuth 2.0 Token Introspection — already exist within the health IT ecosystem.

As ASTP/ONC considers new policies and certification criteria, we urge an approach that establishes strong functional and user experience requirements rather than imposing premature technical lock-in. By focusing on required outcomes — specifically around a unified authorization experience and access to full-fidelity imaging data — ASTP/ONC can create a forcing function that spurs the market to converge on the underlying technical details.

Below, we discuss the key issues and rationale, and then offer three recommendations with sample regulatory language that ASTP/ONC could adopt.

Preventing Fragmentation in Developer and User Experience

Currently, most apps have no automated API pathway to access imaging data. As ASTP/ONC moves to correct this, there is a risk of introducing requirements that expect PACS or VNAs to act as independent certified systems with standalone functionality analogous to a “Base EHR”. Doing so would multiply administrative burden and fracture sign-in and authorization, forcing developers, patients and providers to create, manage, and navigate separate accounts and identities and manage disjointed authorization flows.

To prevent such fragmentation, ASTP/ONC should establish a functional requirement for a single, tightly bound authorization flow where the EHR acts as the identity and authorization authority, and the imaging system serves the imaging data. This unified approach must seamlessly address four concerns:

Patients launching SMART Apps. Consumers should not need to manage separate credentials or sign-ins for imaging systems. They should experience a unified SMART on FHIR authorization flow consistent with existing clinical data workflows, where they can make granular scope selections and approve access to clinical and imaging data.

Clinicians launching SMART Apps. Providers expect a zero-click app launch experience from within an EHR, consistent with existing SMART launch expectations. This typically means organizational access policies apply automatically without requiring the clinician to navigate each authorization screen. The system must support these seamless launches to access a combined set of clinical and imaging data.

Backend Services. Organizational systems performing bulk analytics, AI processing, or population-level care management need a fully automatable pathway to connect to both clinical metadata and the underlying imaging binaries without a user in the loop.

App Developers. Developers should not be required to register their application separately with the EHR and each imaging system.

This unified pathway complements but does not preclude other access models; it establishes a baseline that every patient and developer can rely on.

The industry has already proven that this unified architecture is feasible using today’s technology. In 2023, the Argonaut Project refined and adopted the token introspection model originally pioneered by the NIH-funded Sync for Science project. In 2025, Argonaut participants also successfully explored an additional “Dual SMART Launch” model. Both pathways leverage existing certified capabilities of EHRs (e.g., SMART on FHIR, OAuth 2.0, OpenID Connect and Token Introspection) to meet the functional requirements above. Other designs are also possible and may reflect different implementation trade-offs.

ASTP/ONC does not need to pick a “winning” technical pathway at this stage. By setting the functional expectation for unified access, the industry can align on the implementation details under the pressure of future rulemaking — a measured but powerful regulatory approach that was initially deployed to drive industry consensus on SMART on FHIR a decade ago.

See Recommendation 1 below.

From Metadata to Images: Closing the Certification Gap

The proposed USCDI v7 data element “Diagnostic Imaging Reference” is a strong architectural step. As proposed, it represents a computable reference that enables access to diagnostic imaging studies, series, or individual images. We strongly support this direction; it is appropriate for EHRs to index and exchange this metadata.

However, the USCDI definition itself recognizes that “realizing these benefits requires interoperability agreements with the organizations hosting the PACS or imaging servers where studies are stored.” The USCDI, by design, specifies what data are exchanged, not how. Without accompanying API capabilities and certification criteria in the health IT ecosystem, a computable reference has no system to point to, and apps have no way to dereference it. The data element risks becoming a “bridge to nowhere” — metadata pointing to studies no application can retrieve. Certification should ensure that references can be resolved to bytes.

Closing this gap requires action on two fronts. PACS and VNAs are specialized systems optimized for heavy binary data; forcing them to certify as a “Base EHR” makes no architectural or commercial sense. Instead, a narrow, focused certification criterion should allow imaging systems to demonstrate their participation in interoperable imaging access — specifically, serving imaging data via a standard API and honoring delegated authorization from a Base EHR. Critically, this focused criterion lowers the barrier to entry for imaging vendors: rather than requiring them to build EHR-level identity management and support the full breadth of clinical data, it allows them to certify against a small set of capabilities squarely within their core competency. Conversely, Base EHRs must support flexible permissioning that explicitly governs access to linked imaging data, just as they support flexible scopes for clinical data today.

Importantly, if the Base EHR requirements are specified clearly (see Recommendation 2), the architecture does not depend on every PACS vendor achieving certification. Any system that serves DICOM data via a standard API and honors delegated authorization can participate — whether that is a certified commercial PACS, an open-source imaging proxy, or a lightweight DICOMweb facade built by a health system. The focused imaging certification (see Recommendation 3) provides a valuable conformance signal but is not a bottleneck.

See Recommendations 2 and 3 below.

Access Policies, Proxy Access, and Consent

Proxy access (e.g., a parent accessing a child’s records) and granular consent are notoriously complex. Real-world EHR deployments already manage complex, organization-specific policies around sensitive data categories including reproductive health, behavioral health, and adolescent records. By delegating imaging access policy to the EHR, this architecture leverages that existing investment rather than requiring imaging systems to replicate it.

For common cases (e.g., individuals accessing their own data or clinicians with full care responsibility) these issues are limited. In more complex scenarios, the architecture we propose provides a clean solution: as EHRs store and manage the imaging metadata, they naturally filter what metadata is visible based on existing internal policy choices. External application access to images is thereby limited according to the same well-established policies the EHRs already enforce. The imaging system simply needs to honor the access granted by the EHR.

This principle is embedded in Recommendations 1 and 2 below.

Image Format Requirements: Focus on Full-Fidelity Access

The primary functional requirement must be access to full-fidelity, diagnostic-quality DICOM data, which enables secondary opinions, research, and AI analysis. Consumer-facing rendered previews are a valuable usability layer, and we support their inclusion as an expected capability, but they must not substitute for or delay requirements around full-fidelity access.

Imaging systems already routinely serve large studies over institutional and wide-area networks; API-based access does not introduce fundamentally new scalability challenges, and standard approaches are well-established in the DICOMweb specification.

While DICOMweb APIs do support rendering, and it is reasonable for ASTP/ONC to expect or encourage preview rendering for convenience, the core mandate must focus on the ability to navigate, select, and retrieve full diagnostic studies and individual series using the EHR’s metadata.

See Recommendation 3 below.

---

Recommendations

Recommendation 1: Articulate a Functional Vision for Imaging Interoperability

ASTP/ONC should articulate a clear functional vision for how imaging data access must work within the certified health IT ecosystem. This vision should define the required end-state from the perspective of patients, clinicians, backend services, and app developers — without mandating specific technical implementations at this stage.

This approach leverages the Base EHR’s  role in identity, authorization, and policy enforcement as a practical anchor point in today’s ecosystem. It does not presume that the EHR is the exclusive or permanent locus of innovation, but rather establishes a stable coordination layer upon which competitive applications and services can evolve.

The functional vision should establish that:

• A patient authorizing access to their health data experiences a single sign-in and unified authorization flow that encompasses both clinical and imaging data.
• A clinician launching a SMART app from within an EHR can access clinical and imaging data through a seamless, zero-click experience governed by organizational policy.
• A backend service can access clinical and imaging data through a fully automated process without user interaction.
• An app developer registers their application once with a Base EHR and is not required to complete separate registration with each imaging system.
• Any imaging reference returned by an API is programmatically dereferenceable by an authorized application without additional user interaction.
• Access to imaging data is governed by the same access policies — including proxy access and consent policies — that the EHR applies to clinical data.

ASTP/ONC has multiple levers to establish and drive toward this vision. Regulatory preamble language in a future rule can signal the direction and set expectations for the industry, as was done effectively to catalyze adoption of SMART on FHIR a decade ago. The SVAP process can accelerate adoption of maturing technical standards without requiring a full rulemaking cycle. Beyond rulemaking, ASTP/ONC can use its convening power to bring EHR and imaging vendors together around implementation guidance, fund LEAP challenge awards to demonstrate reference implementations, and support community-driven standards development through staff participation in initiatives such as the Argonaut Project and HL7.

Recommendation 2: Base EHR Requirements for Imaging Interoperability

ASTP/ONC should extend existing Base EHR certification criteria to require support for imaging interoperability. These requirements ensure that the EHR fulfills its role as the identity and authorization authority for imaging access, exposes actionable imaging metadata, and applies its existing access policies to imaging data.

If these Base EHR requirements are clearly specified, the architecture works regardless of whether any particular imaging system is certified — because the EHR’s contract is clear enough that any conformant imaging system (certified, open-source, or otherwise) can plug in.

Sample language:

A Health IT Module certified as a Base EHR must support the following capabilities for diagnostic imaging interoperability:

(a) Imaging Authorization Scopes. The Health IT Module must support authorization scopes that govern access to linked diagnostic imaging data through the same scope-based mechanisms used for clinical data under §170.315(g)(10). Scopes must be available at the patient, user, and system level, consistent with the SMART App Launch v2 framework (e.g., patient/ImagingStudy.rs, user/ImagingStudy.rs, system/ImagingStudy.rs).

(b) Actionable Imaging Metadata. The Health IT Module must expose imaging study metadata (e.g., the FHIR ImagingStudy resource) that includes actionable endpoint references (e.g., DICOMweb WADO-RS URLs embedded within the FHIR ImagingStudy resource) enabling an authorized application to retrieve imaging data from the imaging system.

(c) Unified User-Facing Authorization. When a patient or provider authorizes access to clinical data, the Health IT Module must enable that authorization to extend to diagnostic imaging data within the same sign-in. The user must not be required to authenticate separately with the imaging system or manage separate credentials.

(d) Automated Backend Access. The Health IT Module must enable authorized backend services to access diagnostic imaging data through a fully automated authorization process without requiring user interaction.

(e) Single Application Registration. The Health IT Module must not require an application to complete a separate registration process with an imaging system as a condition of accessing diagnostic imaging data. An application registered with the Health IT Module must be able to access linked imaging data through its authorization with that Base EHR.

(f) Policy-Governed Authorization. Imaging metadata is subject to the same access policies the Health IT Module applies to any other USCDI data. The Health IT Module must be capable of communicating to an imaging system the imaging data that should be accessible in a given authorization context, so that the imaging system can enforce access consistently without independent policy logic.

Recommendation 3: Focused Certification Criteria for Imaging Systems

ASTP/ONC should establish a focused certification criterion for imaging systems (PACS, VNA, or similar) that allows these systems to demonstrate their ability to participate in interoperable imaging access. This criterion should be distinct from Base EHR certification and should not require imaging systems to support clinical data elements (medications, labs, vitals, etc.) that are outside their core function.

This certification provides a conformance signal for the market, but the architecture established in Recommendation 2 does not depend on it. Any imaging system — certified or not — that meets these functional requirements can interoperate with a compliant Base EHR.

Sample language: