SMART Health IT Comments on ASTP HTI-2 Proposed Rule

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

October 1, 2024

Thank you for the opportunity to comment on the HTI-2 proposed rule! We strongly support the ASTP proposals in the rule that expand the use of open standards in healthcare, and believe they will drive innovation that empowers patients, improves care and reduces costs. 

With regard to the Bulk Data Export certification requirement, we agree with ASTP that server support for the _since and _type parameters is a powerful mechanism to reduce the export of extraneous data and improve patient privacy. ASTP notes the lack of a standard process for creating the groups necessary for invoking the “group-export” operation. There is early work in the Argonaut Project to enhance the Bulk Data Access IG in this area, and we propose a general requirement based on the FHIR Group API that can later be updated to a more specific approach, such as the work being done in Argonaut, through the SVAP process. Finally, we propose the inclusion of an export performance parity provision in HTI-2 to better align the capabilities implemented for regulated bulk data interfaces with those of non-regulated, proprietary bulk data interfaces. 

We applaud ASTP for addressing the challenges associated with EHI Export in the HTI-2 proposed rule. To ensure this critical capability is meeting patent needs, we propose additional functional requirements for EHI download functionality in patient portals, EHI access via third-party apps and the adoption of a common approach for non-computable EHI formats (e.g., PDF or HTML).

Medical images are a critical data element for clinical decisions and we strongly support their inclusion in the proposed rule. However, we are concerned that the proposed manner of relying on “imaging links” as the only API-based (i.e., programmatic, automatable) path to access images could fail to solve the access problem. We recommend clarifications to the API requirement to ensure that implementations meet the intent of the rule.

We commend ASTP’s proposal to require subscription capabilities for US Core data. This addition is crucial for enabling real-time data exchange and supporting various use cases across clinical, individual access, and public health domains. However, we recognize that implementing a comprehensive subscription system to provide visibility into all FHIR data changes would present implementation challenges for many real-world EHR systems. We believe a phased approach that prioritizes simplicity and alignment with existing standards can serve to establish a solid foundation for subscription-based data exchange while allowing for future expansion based on real-world experience and feedback and point ASTP to the Argonaut Project’s recent work in this area.

The adoption of dynamic registration for healthcare applications will simplify how apps can securely connect with EHR systems. The proposed rule focuses on using CA-signed certificates and trust communities for dynamic registration. This approach, while robust, may unintentionally exclude individuals and hobbyists who want to explore and innovate with healthcare data in limited contexts, such as individuals developing apps to meet their own health needs or those of friends/family. We recommend a requirement for EHR systems supporting dynamic registration to also accept self-signed certificates for application identity when registering via the HL7 UDAP Security for Scalable Registration IG. By providing users with information on the registrant, a capability present today in app registration systems from vendors such as Epic and Oracle Cerner, this  approach can provide necessary flexibility without compromising security.

Finally, as AI driven recommendations become more prevalent in healthcare, the ability to integrate them into EHR systems through a standards based, interoperable interface is essential for their deployment, monitoring, evaluation and substitutability. In this context, we are excited by the inclusion of the CDS Hooks 2.0 specification in the proposed rule and view this as a core component to build a robust AI ecosystem in healthcare.

FHIR Bulk Data Enhancements

Export Performance Parity

ASTP notes the performance challenges identified by early adopters of the Bulk FHIR interfaces in certified EHR systems. For example, some vendors currently support high performance, non-standard bulk data export of clinical data through a data warehouse product and lower performance, FHIR based bulk data export of clinical data through their transactional system.

Congress explicitly mandated in the 21st Century Cures Act that “interoperability” encompass “complete access, exchange, and use of all electronically accessible health information” and that health IT developers “allow health information from such technology to be accessed, exchanged, and used without special effort through the use of application programming interfaces”.  A reasonable interpretation is that the API must be performant. 

As cited in the Proposed Rule, we have documented poor API performance in EHRs at multiple sites of care1. In contrast, we have also demonstrated capacity for a large health information exchange to rapidly implement the a highly performant Bulk FHIR API in a matter of weeks2

Unfortunately, currently, regulated interfaces in EHRs often perform more poorly than proprietary interfaces and act as a tax on developers and users by making many use cases unworkable using the regulated interface, forcing them to build different versions of their software for each vendor, and often pay additional fees on top of the cost of their certified system just to have access to performant data export.

This harms innovation in healthcare by causing otherwise promising projects to be too costly to pursue, and reduces equity by restricting the ability of institutions with limited resources to participate in research in the same way as larger institutions. Being pushed into proprietary interfaces also serves to lock healthcare institutions into their current EHR vendor, as software built to these interfaces is not portable when an institution changes its EHR. 

We propose an export performance parity provision in HTI-2 to better align the capabilities of regulated bulk data interfaces with those of non-regulated, proprietary bulk data interfaces. 

Our Recommendations:

For any Health IT Module that is part of a system capable of exporting electronic health information for multiple patients simultaneously, and where this information includes data elements from the USCDI v3 dataset:

  1. The system must support the FHIR bulk data export operation for such exports.

  2. The FHIR bulk data export operation must meet the following criteria

    • Performance: The speed and efficiency of data retrieval and export must be comparable to that of non-FHIR export formats (e.g., CSV) when exporting similar volumes of data for a comparable number of patients on equivalent hardware. 

    • Scalability: The system’s ability to handle increasing data volumes and patient numbers must not be significantly different between FHIR and non-FHIR export methods.

    • Timeliness: The currency and up-to-date nature of exported data must be equivalent across FHIR and non-FHIR export methods.

    • Customization: Users must have similar capabilities to tailor the scope and content of exports (e.g., selecting specific data fields or date ranges) in FHIR bulk data exports as they do in non-FHIR export formats.

  3. Vendors must provide documentation demonstrating compliance with these requirements as part of the certification process.

  4. Vendors must provide system administrators with the ability to review metrics about recent bulk and non-bulk exports including the volume of data retrieved and the time to generate and retrieve the export.

Server support for patient group creation

ASTP notes the lack of a standard process for creating the groups necessary for invoking the “group- export” operation and the group size limitations present in some systems. The community has begun the process of defining an API for standardized creation of cohorts for use in bulk export at https://build.fhir.org/ig/HL7/bulk-data/branches/argo24/group.html. We recommend that the ASTP review this preliminary work and consider signaling its potential adoption in a future rule. We propose that the ASTP require EHR systems to support the creation, modification and deletion of FHIR Group resources with no size restrictions other than the total number of patients in the system. When the community reaches consensus on an update to the Bulk Data Access IG to standardize this approach, it could be supported in the regulation through the SVAP process.

Server support for _since and _type

We strongly support the ASTP proposal to require server support for _since and _type since enabling users to scope the output of a bulk export operation to their needs will limit the export of extraneous data and improve patient privacy. 

Useful support for the _since parameter necessitates that EHR systems track when content in FHIR resources are updated and apply this criteria to the data being returned. We propose that EHR systems apply the same criteria used to trigger a subscription notification for a resource to track these changes so the data returned in response to an _since parameter meets user expectations and aligns with the subscription requirements proposed in HTI-2.

EHI Export

We applaud ASTP for addressing the challenges associated with EHI Export in the HTI-2 proposed rule. However, we are concerned that the proposed approach to EHI Export does ensure consistent and user-friendly access to full EHI for all patients.

Congress explicitly mandated in the 21st Century Cures Act that “interoperability” encompass “complete access, exchange, and use of all electronically accessible health information” and that health IT developers “allow health information from such technology to be accessed, exchanged, and used without special effort through the use of application programming interfaces”. This indicates that patients should have ready access to their full EHI, ideally through automated, standards-based mechanisms.

ASTP’s proposed rule falls short of fulfilling this Congressional intent. The current process for requesting full EHI often burdens patients with navigating a confusing patchwork of health system-specific and vendor-specific processes that involve multiple phone calls, emails, and faxes. This creates significant barriers to patient access and control over their own health information. Indeed, under ONC funding we developed a prototype based on the Argonaut implementation guide, which could serve as a starting point3.

Our Recommendations:

To achieve the Congressional vision of complete access to EHI, we urge ASTP to adopt the following functional requirements for certified health IT:

  1. EHI Download Functionality in Patient Portals: ASTP should establish a functional requirement that certified health IT include built-in functionality for patients to request a full EHI export directly through their patient portal. This download may require asynchronous participation from health system staff before it is fulfilled, but should not require additional interaction from the patient, and should notify the patient when the export has finished and the files are ready to download.

  2. EHI Access via Third-Party Apps: ASTP should establish a functional requirement that patients be able to approve sharing their full EHI with third-party applications through the same authorization flow that is used for sharing “US Core” data. This would leverage the existing SMART on FHIR framework already mandated for USCDI data access.

Note: This functional requirement does not necessitate standardizing the API or data models for EHI. Rather, it ensures that patients have a clear and consistent process to authorize access to their complete medical records, paving the way for future standardization. To encourage industry alignment and promote interoperability, we strongly recommend that ASTP review the Argonaut Project’s EHI API Implementation Guide (https://build.fhir.org/ig/argonautproject/ehi-api/) and consider signaling its potential adoption in a future rule.

  1. Common approach for non-computable EHI formats (e.g., PDF or HTML): ASTP should establish a functional requirement that certified health IT include built-in functionality for patients to request a EHI in non-compatible formats using the methods described in #1, and #2 above. The ability to retrieve and share their EHI in either non-computable and computable formats through a single workflow at each healthcare site will reduce the learning curve for patients and enable clearer documentation of the steps involved. This is important, since patients with complex conditions often have the greatest need to obtain their EHI from sites of care, but also may be the most limited in their time and ability to successfully navigate the records request process at each institution.

By implementing these recommendations, ASTP would empower patients with greater control over their health information, foster innovation in patient-facing applications, and drive progress towards a truly interoperable healthcare system.

Image Links in API Responses

We applaud ASTP’s initiative to improve the accessibility of medical images through the proposed rulemaking. However, we are concerned that the proposed manner of relying on “imaging links” as the only API-based (i.e., programmatic, automatable) path to access images could fail to solve the access problem. 

The Proposed Rule does not ensure that links are shareable or that links enable automated access. With these limitations, API access to Imaging Links would fail to meet the policy objective of enabling applications to access imaging data. For example, the following concerns apply:

  • Contextual Restrictions: Imaging Links might be bound to specific user authorization context, network, or timespan, irrespective of the intent of the authorizing user. A link that works in one context (say, for a particular user or in a particular jurisdiction) may be unusable in another context (say, for a new treating provider in another jurisdiction), making the link unshareable.

  • Obstacles to Automation: Imaging Links returned in API responses could lead to a broken or incoherent experience for application users. APIs might return links intended for human rather than machine consumption, preventing apps from dereferencing the links to retrieve imaging content.

Our Recommendations:

  1. Maintain Proposed Functional Requirements for “View and Download” of images: ASTP’s proposed requirements for patient View and Download access (i.e., access to diagnostic quality images, not links) are crucial for establishing common patterns of data access. These should be maintained.

  2. Clarify the Imaging Links API Requirement to ensure programmatic access is enabled: ASTP should clarify the proposed API requirements to ensure that certified systems enable end-to-end automated access to imaging data. This approach can stop short of naming standards, because a carefully designed functional API requirement should encourage EHR and PACS vendors to collaborate on integration strategies that provide a cohesive and user-friendly experience. These clarifications can be introduced in a way that maintains consistency with the Proposed Rule. The critical clarifications are:

    • Ensure that a patient can authorize API access to imaging data in the same flow where they authorize access to clinical data.

    • Ensure that any “Imaging Links” returned by the API will enable programmatic access, meaning that an authorized application can dereference the link to access imaging data without additional user interaction.

    • Note: These functional requirements could be met by using the Imaging API documented at https://github.com/sync-for-science/imaging. In this scheme, developed as part of the Sync for Science project in 2018 and refined by the Argonaut Project in 2023, a FHIR server returns an ImagingStudy with reference to a DICOM Web endpoint, and the app can access the DICOM Web “Imaging Link” programmatically, using the same authorization that granted access to the FHIR API.

  3. Encourage Industry Collaboration on Best Practices: ASTP should suggest that EHR and PACS vendors can meet the functional requirements above by building on work from industry initiatives like the Argonaut Project. Signaling the desire to include standards in a future rule would help drive industry progress on implementation guidance, while ensuring working (if variable) API access in the interim.

Subscriptions for US Core Data

We commend ASTP’s proposal to require subscription capabilities for US Core data. This addition is crucial for enabling real-time data exchange and supporting various use cases across clinical, individual access, and public health domains. Subscriptions will significantly improve the timeliness and efficiency of data sharing.

However, we recognize that implementing a comprehensive subscription system to provide visibility into all FHIR data changes would present implementation challenges for many real-world EHR systems. We believe an initial requirement focusing on the most important data changes would allow for a more manageable implementation process while still delivering significant value. A phased approach prioritizes simplicity and alignment with existing standards, establishing a solid foundation for subscription-based data exchange while allowing for future expansion based on real-world experience and feedback.

We believe the Argonaut Project’s draft design for a US Core Patient Data feed at https://github.com/argonautproject/us-core-patient-data-feed/blob/main/spec.md forms a solid basis for ASTP requirements. Briefly, the design provides:

  • A single topic that allows access to any patient-linked data in US Core, but initially requires support for only a small set of data including DocumentReference, Encounter, DiagnosticReport, Observation resources.

  • Ability to subscribe to data with or without a “patient=” filter, meaning that apps can subscribe to a single patient’s data or a cross-patient feed (e.g. for public health or clinical enrollment systems).

  • Flexibility for servers to send notifications on a key set of important lifecycle events, rather than requiring every FHIR-visible change to trigger a notification.

Our Recommendations:

  1. Version Alignment: Refer to version 1.1 of the Topic-Based Subscriptions Backport IG, with the option to support version 1.2 via SVAP after version 1.2 is published.

  2. Subscription Topic: Describe a single Patient Data Feed similar to the Argonaut Project’s draft design, rather than introducing distinct concepts of “USCDI change notifications” and “Resource notifications”. 

  3. Phased Expansion: Begin with a limited set of required FHIR resources and expand over time to cover all of USCDI.

  4. Focused Filters: Align filter requirements with existing US Core search parameters, reducing implementation complexity.

  5. Flexibility in Trigger Implementation: Require notifications for resource status changes (create, update, delete) but allow flexibility for servers in determining which underlying EHR system events will trigger “update” notifications.

  6. US Core Integration: Support the development of subscription guidance within US Core to provide a cohesive set of standards for implementers.

Dynamic Registration outside of Trust Frameworks

We applaud ASTP’s proposed adoption of dynamic registration for healthcare applications, simplifying and securing how apps connect with EHR systems. We recommend an important addition to the proposed rule to ensure dynamic registration is accessible to everyone: require EHR systems supporting dynamic registration to also accept self-signed certificates for application identity when registering via the HL7 UDAP Security for Scalable Registration IG. 

The proposed rule focuses on using CA-signed certificates and trust communities for dynamic registration. This approach, while robust, may unintentionally exclude individuals and hobbyists who want to explore and innovate with healthcare data in limited contexts, such as individuals developing apps to meet their own health needs or those of friends/family. Requiring these individuals to join trust communities creates an unnecessary barrier to entry, limiting their ability to participate in the API ecosystem.

Notably, this change provides necessary flexibility without compromising security, as EHR systems can still inform users that an app’s identity is self-attested when authorizing access to apps using self-signed certificates. Similarly, current app registration approaches from vendors such as Epic and Oracle Cerner provide information to app users about the app’s registrant, but do not censor non-fraudulent registrations by individuals. 

Proposed Language Modification: Add the following to §170.315(j)(2), “Dynamic registration” – “A Health IT Module supporting dynamic registration under §170.215(o) must also support self-signed certificates for application identity.”

Expanding dynamic registration access will foster creativity and empower individuals to engage with their healthcare data in new and beneficial ways.

CDS Hooks

We applaud ASTP’s inclusion of CDS Hooks 2.0 as a certification requirement as well as the requirements for patient-view and order-sign hooks. As AI driven recommendations become more prevalent in healthcare, the ability to integrate them into EHR systems through a standards based, interoperable interface is essential for their deployment, monitoring, evaluation and substitutability. For example, a standards based DSI that integrates with EHR systems though CDS Hooks could be tested with a site’s data prior to implementation using a CDS Hooks simulator environment, rather than requiring custom infrastructure.

Bibliography 

  1. Jones JR, Gottlieb D, McMurry AJ, Atreja A, Desai PM, Dixon BE, Payne PRO, Saldanha AJ, Shankar P, Solad Y, Wilcox AB, Ali MS, Kang E, Martin AM, Sprouse E, Taylor DE, Terry M, Ignatov V, SMART Cumulus Network, Mandl KD. Real world performance of the 21st Century Cures Act population-level application programming interface. J Am Med Inform Assoc [Internet]. 2024 Mar 6; Available from: http://dx.doi.org/10.1093/jamia/ocae040 PMID: 38447593 ↩︎
  2. McMurry AJ, Gottlieb D, Miller TA, Jones JR, Atreja A, Crago J, Desai PM, Dixon BE, Garber M, Ignatov V, Kirchner LA, Payne PRO, Saldanha AJ, Shankar PRV, Solad YV, Sprouse EA, Terry M, Wilcox AB, Mandl KD. Cumulus: a federated electronic health record-based learning system powered by Fast Healthcare Interoperability Resources and artificial intelligence. J Am Med Inform Assoc [Internet]. 2024 Jun 11; Available from: http://dx.doi.org/10.1093/jamia/ocae130 PMID: 38860521 ↩︎
  3. Phelan D, Gottlieb D, Mandel JC, Ignatov V, Jones J, Marquard B, Ellis A, Mandl KD. Beyond compliance with the 21st Century Cures Act Rule: a patient controlled electronic health information export application programming interface. J Am Med Inform Assoc [Internet]. 2024 Jan 29; Available from: http://dx.doi.org/10.1093/jamia/ocae013 PMID: 38287642 ↩︎