§170.315(b)(10) Electronic Health Information export

Clarifications:

• EHI means “electronic protected health information” (ePHI) as defined in 45 CFR 160.103 to the extent that it would be included in a designated record set as defined in 45 CFR 164.501, regardless of whether the group of records are used or maintained by or for a covered entity. But EHI does not include psychotherapy notes as defined in 45 CFR 164.501 or information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding.
• The EHI definition represents the same ePHI that a patient would have the right to request a copy of pursuant to the HIPAA Privacy Rule.
• The criterion is specific to EHI, as defined above, that can be stored by the health IT product at the time the Health IT Module is presented for certification. 
• Conformance “at the time of certification” means the combined data that is stored in and by the Health IT Module in its original form as presented for certification. It does not include within the certification criterion’s scope of export any data subsequently generated from unique post-certification deployments.
• The criterion does not specify transport method(s) or data standards that must be used.
• The criterion does not specify a predefined data set and will differ by developer and products of which the Health IT Module is a part. As a result, the amount of EHI that will need to be able to be exported in order to demonstrate conformance with this certification criterion will vary widely because of the diversity of products presented for certification.
• “Stored” data applies to all EHI and is agnostic as to whether the EHI is stored in or by the Certified Health IT Module or in or by any of the other “non-certified” capabilities of the health IT product of which the Certified Health IT Module is a part.
• “Can be stored by” refers to the EHI types stored in and by the health IT product, of which the Health IT Module is a part and is meant to be interpreted as the combination of EHI a heath IT product stores itself and in other data storage locations. Thus, the cumulative data covered by these storage techniques would be in the scope of data export.
• Any images, imaging information, and image elements that fall within this finalized scope of EHI that can be stored at the time of certification in or by the product, of which the Health IT Module is a part, will need to be exported under this certification criterion.
• In the context of imaging, if the only EHI stored in or by the product to which this certification criterion applies are links to images/imaging data (and not the images themselves, which may remain in a picture archiving and communication system (PACS)) then only such links must be part of what is exported.
• This certification criterion also does not prescribe how (i.e., media/medium) the exported information is to be made available to the user, as this may depend on the size and type of information to be exported.
• The export format need not be the same format used internally by the certified health IT, and the health IT developer does not need to make public its proprietary data model.
• The file formats and related definitions are not finalized as specific certification requirements, developers are encouraged to continue to foster transparency and best practices for data sharing, such as machine-readable format, when they create and update their export format information
• The documentation for the export format consists of information on the structure and syntax for how the EHI will be exported by the product such as, for example, Consolidated-Clinical Document Architecture (C-CDA) document(s) or data dictionary for comma separated values (csv) file(s), and not the actual EHI. This documentation must be made available through a publicly accessible hyperlink. 
• Health IT developers must keep the documentation related to the export format “up-to-date.” For example, if the health IT developer had previously specified the C-CDA standard as the export format for meeting the criterion, but subsequently updated its product to use the FHIR® standard and stopped supporting C-CDA export format, then the documentation for export format, which is made available through the publicly accessible hyperlink, would need to be updated so that users are able to continue to accurately process the EHI exported by the product.
• Health IT developers have until December 31, 2023 to test and certify to the updated 2015 Edition Cures Update. [see IFR]
• The (b)(10) EHI Export certification criterion does not prescribe how the exported information is to be made available to the user, as this may depend on the size and type of information to be exported. The file formats and related definitions also are not finalized as specific certification requirements, though developers are encouraged to continue to foster transparency and best practices for data sharing when they create and update their export format information. However, the export file(s) created must be electronic and in a computable format.
• There is nothing that proscribes the use of PDF to meet the certification requirements for (b)(10) EHI Export, provided the requirement for "computable format" is met by the PDF produced. If it is necessary to produce a PDF for the purpose of meeting this provision, the PDF must be an interpretable, machine-readable output. While this may be possible for some PDFs, other PDFs, such as those that include EHI as images, generally might not be an interpretable, machine-readable output. One way a PDF could be a machine-readable format would be if it was structured so that the data it conveyed could be consumed or imported by another software program using consistent processing logic, consistent with the National Institute of Standards and Technology’s definition of “machine-readable.” If a data output format is structured so that the EHI it conveys is machine readable and computable, then that output format is a machine-readable and computable format, regardless of the file extension.

Technical outcome – Enable a user to timely create an export file(s) with all of a single patient’s electronic health information stored at the time of certification by the product, of which the Health IT Module is a part.

Clarifications:

• “Timely” means near real-time, while being reasonable and prudent given the circumstances.

Technical outcome – A user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate.

Clarifications:

• No additional clarifications.

Technical outcome – Limit the ability of users who can create export file(s) in at least one of these two ways: (1) To a specific set of identified users (2) As a system administrative function.

Clarifications:

• “User” is a health care professional or his or her office staff; or a software program or service that would interact directly with the certified health IT (see also 80 FR 62611, 77 FR 54168).
• The ability to limit the health IT users’ access to the single patient EHI export functionality in § 170.315(b)(10)(i) is intended to be used by and at the discretion of the organization implementing the technology.  This cannot be used by health IT developers as a way to thwart or moot the overarching user-driven aspect of this capability (see also 80 FR 62646).
• This certification criterion does not require “direct-to-patient” functionality in order to demonstrate conformance. The capability to execute this certification criterion can be health care provider/health care organization initiated (presumably upon that organization receiving a request by patient for his or her EHI).

Technical outcome – The export files(s) created must be electronic and in a computable format.

Clarifications:

• No additional clarifications.

Technical outcome – The publicly accessible hyperlink of the export’s format must be included with the exported file(s).

Clarifications:

• No additional clarifications.

Technical outcome – Create an export of all the electronic health information that can be stored at the time of certification by product of which the Health IT Module is a part.

Clarifications:

• The patient population EHI export capability of this criterion could require action or support on the part of the health IT developer.
• For the (b)(10)(ii) requirements for patient population export, ONC does not specify requirements as to how the export must be initiated or processed. However, for (b)(10)(ii) conformance, developer must ensure that an export can be created for all the electronic health information that can be stored at the time of certification by the product of which the Health IT Module is a part. Note that developers are also required under the § 170.402 Assurances Condition of Certification to ensure full compliance and unrestricted implementation of the (b)(10) functionality, including patient population export.

Technical outcome – The exported format(s) used to support paragraphs (b)(10)(i) and (ii) of this section must be kept up-to-date.

Clarifications:

• The developer’s clinical EHI export format should be made publicly available via a hyperlink as part of certification to the criterion, including keeping the hyperlink up-to-date with the current export format. Similar to the API documentation, this link will also be made available on the Certified Health IT Product List (CHPL).
• The hyperlink must allow any person to directly access the information without any preconditions or additional steps.