This subpart implements section 3001(c)(5)(D) of the Public Health Service Act by setting forth certain Conditions and Maintenance of Certification requirements for health IT developers participating in the ONC Health IT Certification Program.

(a) Condition of Certification requirement. A health IT developer must not take any action that constitutes information blocking as defined in 42 U.S.C. 300jj-52 and § 171.103 on or after April 5, 2021.

(b) [Reserved]

(a) Condition of Certification requirement. (1) A health IT developer must provide assurances satisfactory to the Secretary that the health IT developer will not take any action that constitutes information blocking as defined in 42 U.S.C. 300jj-52 and § 171.103 of this chapter on and after April 5, 2021, unless for legitimate purposes as specified by the Secretary; or any other action that may inhibit the appropriate exchange, access, and use of electronic health information.

(2) A health IT developer must ensure that its health IT certified under the ONC Health IT Certification Program conforms to the full scope of the certification criteria.

(3) A health IT developer must not take any action that could interfere with a user's ability to access or use certified capabilities for any purpose within the full scope of the technology's certification.

(4) A health IT developer of a certified Health IT Module that is part of a health IT product which electronically stores EHI must certify to the certification criterion in § 170.315(b)(10).

(5) A health IT developer must not inhibit its customer's timely access to interoperable health IT certified under the Program.

(b) Maintenance of Certification requirements. (1) A health IT developer must retain all records and information necessary to demonstrate initial and ongoing compliance with the requirements of the ONC Health IT Certification Program for:

(i) A period of 10 years beginning from the date a developer's Health IT Module(s) is first certified under the Program; or

(ii) If for a shorter period of time, a period of 3 years from the effective date that removes all of the certification criteria to which the developer's health IT is certified from the Code of Federal Regulations.

(2)(i) By December 31, 2023, a health IT developer that must comply with the requirements of paragraph (a)(4) of this section must provide all of its customers of certified health IT with the health IT certified to the certification criterion in § 170.315(b)(10).

(ii) On and after December 31, 2023, a health IT developer that must comply with the requirements of paragraph (a)(4) of this section must provide all of its customers of certified health IT with the health IT certified to the certification criterion in § 170.315(b)(10).

(3)(i) Update. A health IT developer must update a Health IT Module, once certified to a certification criterion adopted in § 170.315, to all applicable revised certification criteria, including the most recently adopted capabilities and standards included in the revised certification criterion.

(ii) Provide. A health IT developer must provide all Health IT Modules certified to a revised certification criterion, including the most recently adopted capabilities and standards included in the revised certification criterion, to its customers of such certified health IT.

(iii) Timeliness. A health IT developer must complete the actions specified in paragraphs (b)(3)(i) and (ii) of this section:

(A) Consistent with the timeframes specified in part 170; or

(B) If the developer obtains new customers of health IT certified to the revised criterion after the effective date of the final rule adopting the revised criterion or criteria, then the health IT developer must provide the health IT certified to the revised criterion to such customers within whichever of the following timeframes that expires last:

(1) The timeframe provided in paragraph (b)(3)(iii)(A) of this section; or

(2) No later than 12 months after the purchasing or licensing relationship has been established between the health IT developer and the new customer for the health IT certified to the revised criterion.

(4) For developers of Health IT Modules certified to § 170.315(b)(11), starting January 1, 2025, and on an ongoing basis thereafter, review and update as necessary source attribute information in § 170.315(b)(11)(iv)(A) and (B), intervention risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi).

(a) Condition of Certification requirements. (1) A health IT developer may not prohibit or restrict any communication regarding—

(i) The usability of its health IT;

(ii) The interoperability of its health IT;

(iii) The security of its health IT;

(iv) Relevant information regarding users' experiences when using its health IT;

(v) The business practices of developers of health IT related to exchanging electronic health information; and

(vi) The manner in which a user of the health IT has used such technology.

(2) A health IT developer must not engage in any practice that prohibits or restricts a communication regarding the subject matters enumerated in paragraph (a)(1) of this section, unless the practice is specifically permitted by this paragraph and complies with all applicable requirements of this paragraph.

(i) Unqualified protection for certain communications. A health IT developer must not prohibit or restrict any person or entity from communicating any information whatsoever (including proprietary information, confidential information, and intellectual property) when the communication is about one or more of the subject matters enumerated in paragraph (a)(1) of this section and is made for any of the following purposes:

(A) Making a disclosure required by law;

(B) Communicating information about adverse events, hazards, and other unsafe conditions to government agencies, health care accreditation organizations, and patient safety organizations;

(C) Communicating information about cybersecurity threats and incidents to government agencies;

(D) Communicating information about information blocking and other unlawful practices to government agencies; or

(E) Communicating information about a health IT developer's failure to comply with a Condition of Certification requirement, or with any other requirement of this part, to ONC or an ONC-ACB.

(ii) Permitted prohibitions and restrictions. For communications about one or more of the subject matters enumerated in paragraph (a)(1) of this section that is not entitled to unqualified protection under paragraph (a)(2)(i) of this section, a health IT developer may prohibit or restrict communications only as expressly permitted by paragraphs (a)(2)(ii)(A) through (E) of this section.

(A) Developer employees and contractors. (1) A health IT developer may prohibit or restrict the communications of the developer's employees or contractors.

(2) A self-developer must not prohibit or restrict communications of users of their health IT who are also employees or contractors.

(B) Non-user-facing aspects of health IT. A health IT developer may prohibit or restrict communications that disclose information about non-user-facing aspects of the developer's health IT.

(C) Intellectual property. A health IT developer may prohibit or restrict communications that involve the use or disclosure of intellectual property existing in the developer's health IT (including third-party intellectual property), provided that any prohibition or restriction imposed by a developer must be no broader than necessary to protect the developer's legitimate intellectual property interests and consistent with all other requirements of paragraph (a)(2)(ii) of this section. A restriction or prohibition is deemed broader than necessary and inconsistent with the requirements of paragraph (a)(2)(ii) of this section if it would restrict or preclude a public display of a portion of a work subject to copyright protection (without regard to whether the copyright is registered) that would reasonably constitute a “fair use” of that work.

(D) Screenshots and video. A health IT developer may require persons who communicate screenshots or video to—

(1) Not alter the screenshots or video, except to annotate the screenshots or video or resize the screenshots or video;

(2) Limit the sharing of screenshots to the relevant number of screenshots needed to communicate about the health IT regarding one or more of the six subject areas in paragraph (a)(1) of this section; and

(3) Limit the sharing of video to:

(i) The relevant amount of video needed to communicate about the health IT regarding one or more of the six subject areas in paragraph (a)(1) of this section; and

(ii) Only videos that address temporal matters that cannot be communicated through screenshots or other forms of communication.

(E) Pre-market testing and development. A health IT developer may prohibit or restrict communications that disclose information or knowledge solely acquired in the course of participating in pre-market product development and testing activities carried out for the benefit of the developer or for the joint benefit of the developer and communicator. A developer must not, once the subject health IT is released or marketed for purposes other than product development and testing, and subject to the permitted prohibitions and restrictions described in paragraph (a)(2)(ii) of this section, prohibit or restrict communications about matters enumerated in paragraph (a)(1) of this section.

(b) Maintenance of Certification requirements—(1) Notice. Health IT developers must issue a written notice to all customers and those with which it has contracts or agreements containing provisions that contravene paragraph (a) of this section annually, beginning in calendar year 2021, until paragraph (b)(2)(ii) of this section is fulfilled, stating that any communication or contract provision that contravenes paragraph (a) of this section will not be enforced by the health IT developer.

(2) Contracts and agreements. (i) A health IT developer must not establish, renew, or enforce any contract or agreement that contravenes paragraph (a) of this section.

(ii) If a health IT developer has a contract or agreement in existence as of June 30, 2020, that contravenes paragraph (a) of this section, then the developer must amend the contract or agreement to remove or void the contractual provision that contravenes paragraph (a) of this section whenever the contract is next modified for other reasons or renewed.

(c) Communication, defined. “Communication” as used in this section means any communication, irrespective of the form or medium. The term includes visual communications, such as screenshots and video.

The following Condition and Maintenance of Certification requirements apply to developers of Health IT Modules certified to any of the certification criteria adopted in § 170.315(g)(7) through (10).

(a) Condition of certification requirements—(1) General. A Certified API Developer must publish APIs and allow electronic health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law, including providing access to all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws.

(2) Transparency conditions—(i) Complete business and technical documentation. A Certified API Developer must publish complete business and technical documentation, including the documentation described in paragraph (a)(2)(ii) of this section, via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps.

(ii) Terms and conditions—(A) Material information. A Certified API Developer must publish all terms and conditions for its certified API technology, including any fees, restrictions, limitations, obligations, registration process requirements, or other similar requirements that would be:

(1) Needed to develop software applications to interact with the certified API technology;

(2) Needed to distribute, deploy, and enable the use of software applications in production environments that use the certified API technology;

(3) Needed to use software applications, including to access, exchange, and use electronic health information by means of the certified API technology;

(4) Needed to use any electronic health information obtained by means of the certified API technology;

(5) Used to verify the authenticity of API Users; and

(6) Used to register software applications.

(B) API fees. Any and all fees charged by a Certified API Developer for the use of its certified API technology must be described in detailed, plain language. The description of the fees must include all material information, including but not limited to:

(1) The persons or classes of persons to whom the fee applies;

(2) The circumstances in which the fee applies; and

(3) The amount of the fee, which for variable fees must include the specific variable(s) and methodology(ies) that will be used to calculate the fee.

(3) Fees conditions—(i) General conditions—(A) All fees. All fees related to certified API technology not otherwise permitted by this section are prohibited from being imposed by a Certified API Developer. The permitted fees in paragraphs (a)(3)(ii) and (iv) of this section may include fees that result in a reasonable profit margin in accordance with § 171.302.

(B) Permitted fees requirements. For all permitted fees, a Certified API Developer must:

(1) Ensure that such fees are based on objective and verifiable criteria that are uniformly applied to all similarly situated API Information Sources and API Users;

(2) Ensure that such fees imposed on API Information Sources are reasonably related to the Certified API Developer's costs to supply certified API technology to, and if applicable, support certified API technology for, API Information Sources;

(3) Ensure that such fees to supply and, if applicable, support certified API technology are reasonably allocated among all similarly situated API Information Sources; and

(4) Ensure that such fees are not based on whether API Information Sources or API Users are competitors, potential competitors, or will be using the certified API technology in a way that facilitates competition with the Certified API Developer.

(C) Prohibited fees. A Certified API Developer is prohibited from charging fees for the following:

(1) Costs associated with intangible assets other than actual development or acquisition costs of such assets;

(2) Opportunity costs unrelated to the access, exchange, or use of electronic health information; and

(3) The permitted fees in this section cannot include any costs that led to the creation of intellectual property if the actor charged a royalty for that intellectual property pursuant to § 171.303 and that royalty included the development costs for the creation of the intellectual property.

(D) Record-keeping requirements. A Certified API Developer must keep for inspection detailed records of any fees charged with respect to the certified API technology, the methodology(ies) used to calculate such fees, and the specific costs to which such fees are attributed.

(ii) Permitted fee—development, deployment, and upgrades. A Certified API Developer is permitted to charge fees to an API Information Source to recover the costs reasonably incurred by the Certified API Developer to develop, deploy, and upgrade certified API technology.

(iii) Permitted fee—recovering API usage costs. A Certified API Developer is permitted to charge fees to an API Information Source related to the use of certified API technology. The fees must be limited to the recovery of incremental costs reasonably incurred by the Certified API Developer when it hosts certified API technology on behalf of the API Information Source.

(iv) Permitted fee—value-added services. A Certified API Developer is permitted to charge fees to an API User for value-added services related to certified API technology, so long as such services are not necessary to efficiently and effectively develop and deploy production-ready software that interacts with certified API technology.

(4) Openness and pro-competitive conditions; general condition. A Certified API Developer must grant an API Information Source the independent ability to permit an API User to interact with the certified API technology deployed by the API Information Source.

(i) Non-discrimination. (A) A Certified API Developer must provide certified API technology to an API Information Source on terms that are no less favorable than it provides to itself and its own customers, suppliers, partners, and other persons with whom it has a business relationship.

(B) The terms on which a Certified API Developer provides certified API technology must be based on objective and verifiable criteria that are uniformly applied to all substantially similar or similarly situated classes of persons and requests.

(C) A Certified API Developer must not offer different terms or services based on:

(1) Whether a competitive relationship exists or would be created;

(2) The revenue or other value that another party may receive from using the API technology.

(ii) Rights to access and use certified API technology—(A) Rights that must be granted. A Certified API Developer must have and, upon request, must grant to API Information Sources and API Users all rights that may be reasonably necessary to:

(1) Access and use the Certified API Developer's certified API technology in a production environment;

(2) Develop products and services that are designed to interact with the Certified API Developer's certified API technology; and

(3) Market, offer, and distribute products and services associated with the Certified API Developer's certified API technology.

(B) Prohibited conduct. A Certified API Developer is prohibited from conditioning the receipt of the rights described in paragraph (a)(4)(ii)(A) of this section on:

(1) Receiving a fee, including but not limited to a license fee, royalty, or revenue-sharing arrangement;

(2) Agreeing to not compete with the Certified API Developer in any product, service, or market;

(3) Agreeing to deal exclusively with the Certified API Developer in any product, service, or market;

(4) Obtaining additional licenses, products, or services that are not related to or can be unbundled from the certified API technology;

(5) Licensing, granting, assigning, or transferring any intellectual property to the Certified API Developer;

(6) Meeting any Certified API Developer-specific testing or certification requirements; and.

(7) Providing the Certified API Developer or its technology with reciprocal access to application data.

(iii) Service and support obligations. A Certified API Developer must provide all support and other services reasonably necessary to enable the effective development, deployment, and use of certified API technology by API Information Sources and API Users in production environments.

(A) Changes and updates to certified API technology. A Certified API Developer must make reasonable efforts to maintain the compatibility of its certified API technology and to otherwise avoid disrupting the use of certified API technology in production environments.

(B) Changes to terms and conditions. Except as exigent circumstances require, prior to making changes to its certified API technology or to the terms and conditions thereof, a Certified API Developer must provide notice and a reasonable opportunity for API Information Sources and API Users to update their applications to preserve compatibility with certified API technology and to comply with applicable terms and conditions.

(b) Maintenance of certification requirements—(1) Authenticity verification and registration for production use. The following apply to a Certified API Developer with a Health IT Module certified to the certification criterion adopted in § 170.315(g)(10):

(i) Authenticity verification. A Certified API Developer is permitted to institute a process to verify the authenticity of API Users so long as such process is objective and the same for all API Users and completed within ten business days of receipt of an API User's request to register their software application for use with the Certified API Developer's Health IT Module certified to § 170.315(g)(10).

(ii) Registration for production use. A Certified API Developer must register and enable all applications for production use within five business days of completing its verification of an API User's authenticity, pursuant to paragraph (b)(1)(i) of this section.

(2) Service base URL publication. For all Health IT Modules certified to § 170.315(g)(10), a Certified API Developer must publish, at no charge, the service base URLs and related organization details that can be used by patients to access their electronic health information, by December 31, 2024. This includes all customers regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source. These service base URLs and organization details must conform to the following:

(i) Service base URLs must be publicly published in Endpoint resource format according to the standard adopted in § 170.215(a).

(ii) Organization details for each service base URL must be publicly published in Organization resource format according to the standard adopted in § 170.215(a). Each Organization resource must contain:

(A) A reference, in the Organization.endpoint element, to the Endpoint resources containing service base URLs managed by this organization.

(B) The organization's name, location, and facility identifier.

(iii) Endpoint and Organization resources must be:

(A) Collected into a Bundle resource formatted according to the standard adopted in § 170.215(a) for publication; and

(B) Reviewed quarterly and, as necessary, updated.

(3) Rollout of (g)(10)-certified APIs. A Certified API Developer with certified API technology previously certified to the certification criterion in § 170.315(g)(8) must provide all API Information Sources with such certified API technology deployed with certified API technology certified to the certification criterion in § 170.315(g)(10) by no later than December 31, 2022.

(4) Compliance for existing certified API technology. By no later than April 5, 2021, a Certified API Developer with Health IT Module(s) certified to the certification criteria in § 170.315(g)(7), (8), or (9) must comply with paragraph (a) of this section, including revisions to their existing business and technical API documentation and make such documentation available via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps.

(c) Definitions. The following definitions apply to this section:

API Information Source means an organization that deploys certified API technology created by a “Certified API Developer;”

API User means a person or entity that creates or uses software applications that interact with the “certified API technology” developed by a “Certified API Developer” and deployed by an “API Information Source;”

Certified API Developer means a health IT developer that creates the “certified API technology” that is certified to any of the certification criteria adopted in § 170.315(g)(7) through (10); and

Certified API technology means the capabilities of Health IT Modules that are certified to any of the API-focused certification criteria adopted in § 170.315(g)(7) through (10).

(a) Condition of Certification requirement. A health IT developer with one or more Health IT Module(s) certified to any one or more of the ONC Certification Criteria for Health IT in § 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h) must successfully test the real world use of those Health IT Module(s) for interoperability (as defined in 42 U.S.C. 300jj(9) and § 170.102) in the type of setting in which such Health IT Module(s) would be/is marketed.

(b) Maintenance of Certification requirements—(1) Real world testing plan submission. A health IT developer with Health IT Module(s) certified to any one or more of the criteria referenced in paragraph (a) of this section must submit to its ONC-ACB an annual real world testing plan addressing each of those certified Health IT Modules by a date determined by the ONC-ACB that enables the ONC-ACB to publish a publicly available hyperlink to the plan on CHPL no later than December 15 of each calendar year, beginning in 2021.

(i) The plan must be approved by a health IT developer authorized representative capable of binding the health IT developer for execution of the plan and include the representative's contact information.

(ii) The plan must include all health IT certified to any one or more of the criteria referenced in paragraph (a) of this section as of August 31 of the year in which the plan is submitted, and address the real world testing to be conducted in the calendar year immediately following plan submission.

(iii) The plan must address the following for each of the certification criteria identified in paragraph (a) of this section that are included in each Health IT Module's scope of certification:

(A) The testing method(s)/methodology(ies) that will be used to demonstrate real world interoperability and conformance to the full scope of the certification criterion's requirements, including scenario- and use case-focused testing;

(B) The care setting(s) that will be tested for real world interoperability and an explanation for the health IT developer's choice of care setting(s) to test;

(C) For any standards and implementation specifications referenced by the criterion that the developer has chosen to certify to National Coordinator-approved newer versions pursuant to paragraph (b)(8) or (9) of this section, a description of how the developer will test and demonstrate conformance to all requirements of the criterion using all versions of the adopted standards to which each Health IT Module was certified as of August 31 of the year in which the real world testing plan is due.

(D) A schedule of key real world testing milestones;

(E) A description of the expected outcomes of real world testing;

(F) At least one measurement/metric associated with the real world testing; and

(G) A justification for the health IT developer's real world testing approach.

(2) Real world testing results reporting. (i) If in the course of conducting real world testing the developer discovers one or more non-conformities with the full scope of any certification criterion under the Program, the developer must report that non-conformity to the ONC-ACB within 30 days.

(ii) For real world testing activities conducted during the immediately preceding calendar year, a health IT developer must submit to its ONC-ACB an annual real world testing results report addressing each of its certified Health IT Modules that include certification criteria referenced in paragraph (a) of this section by a date determined by the ONC-ACB that enables the ONC-ACB to publish a publicly available hyperlink to the results report on CHPL no later than March 15 of each calendar year, beginning in 2023. For certified Health IT Modules included in paragraph (a) of this section that are updated using Inherited Certified Status after August 31 of the year in which the plan is submitted, a health IT developer must include the newer version of the certified Health IT Module(s) in its annual real world testing results report. The real world testing results must report the following for each of the certification criteria identified in paragraph (a) of this section that are included in the Health IT Module's scope of certification:

(A) The method(s) that was used to demonstrate real world interoperability;

(B) The care setting(s) that was tested for real world interoperability;

(C) The voluntary updates to standards and implementation specifications that the National Coordinator has approved through the Standards Version Advancement Process;

(D) A list of the key milestones met during real world testing;

(E) The outcomes of real world testing including a description of any challenges encountered during real world testing; and

(F) At least one measurement/metric associated with the real world testing.

(3)-(7) [Reserved]

(8) Standards Version Advancement Process—voluntary updates of certified health IT to newer versions of standards and implementation specifications. A health IT developer subject to this paragraph (b) is permitted to update Health IT Module(s) certified to any one or more of the certification criteria referenced in paragraph (a) of this section to a newer version of any adopted standard or implementation specification included in the criterion, provided that newer version is approved by the National Coordinator for use in certifications issued under the ONC Health IT Certification Program. A developer that pursues such updates to its certified Health IT Module(s) must:

(i) Provide advance notice to all affected customers and its ONC-ACB—

(A) Expressing its intent to update the certified Health IT Module(s) to the National Coordinator-approved advanced version of the standard implementation specification;

(B) The developer's expectations for how the update(s) will affect real world interoperability for the Health IT Module(s);

(C) Whether the developer intends to continue to support the certificate(s) for the existing certified Health IT Module(s) version(s) for some period of time and how long or if the existing certified Health IT Module(s) version(s) will be deprecated; and

(ii) Successfully demonstrate conformance with approved more recent versions of the standard(s) or implementation specification(s) included in each certification criterion under which the developer chooses to update its certified Health IT Module(s).

(iii) Maintain the updated certified Health IT Module(s) in full conformance with all applicable Program requirements.

(9) Standards Version Advancement Process—voluntary certification to newer versions of standards and implementation specifications. A Health IT developer is permitted to seek certification for its Health IT Module(s) to any one or more of the certification criteria referenced in paragraph (a) of this section using a newer version of any adopted standard(s) or implementation specification(s) included in the criterion without first obtaining certification to the version of that adopted standard or implementation specification that is incorporated by reference in § 170.299, provided that the newer version is approved by the National Coordinator for use in certifications issued under the ONC Health IT Certification Program. Developers may, for each standard and implementation specification included in each criterion, choose on an itemized basis whether to seek certification to the version incorporated by reference in § 170.299, or to one or more newer version(s) approved by the National Coordinator for use in Health IT Module certifications issued pursuant to section 3001(c)(5) of the Public Health Service Act, or to both.

(10) [Reserved]

(a) Condition of Certification requirement. A health IT developer, or its authorized representative that is capable of binding the health IT developer, must provide the Secretary an attestation of compliance with the following Conditions and Maintenance of Certification requirements:

(1) Section 170.401;

(2) Section 170.402, but only for § 170.402(a)(4) and (b)(2) if the health IT developer certified a Health IT Module(s) that is part of a health IT product which can store electronic health information;

(3) Section 170.403;

(4) Section 170.404 if the health IT developer has a Health IT Module(s) certified to any of the certification criteria adopted in § 170.315(g)(7) through (10); and such health IT developer must also ensure that health IT allows for health information to be exchanged, accessed, and used, in the manner described in § 170.404; and

(5) Section 170.405 if a health IT developer has a Health IT Module(s) certified to any one or more ONC Certification Criteria for Health IT in § 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h).

(b) Maintenance of Certification requirement. (1) A health IT developer, or its authorized representative that is capable of binding the health IT developer, must provide the attestation specified in paragraph (a) of this section semiannually for any Health IT Modules that have or have had an active certification at any time under the ONC Health IT Certification Program during the prior six months.

(2) [Reserved] [85 FR 25945, May 1, 2020, as amended at 89 FR 8549, Feb. 8, 2024]

(a) Condition of Certification—(1) Measure responses. A health IT developer must submit (to the independent entity designated by the Secretary) for each reporting period pursuant to paragraph (b) of this section:

(i) Responses for the measures specified in this section, which must include:

(A) Data aggregated at the product level (across versions);

(B) Documentation related to the data sources and methodology used to generate measures; and

(C) Percentage of total customers (e.g., hospital sites, individual clinician users) represented in provided data; or

(ii) A response (attestation) that it does not:

(A) Meet the minimum reporting qualifications requirement in paragraph (a)(2) of this section; or

(B) Have health IT certified to the certification criteria specified in each measure in paragraphs (a)(3)(i) through (vii) of this section; or

(C) Have any users using the certified health IT specified in each measure in paragraphs (a)(3)(i) through (vii) of this section during the reporting period.

(2) Minimum reporting qualifications requirement. At least 50 hospital sites or 500 individual clinician users across the developer's certified health IT.

(3) Measures—(i) Individuals' access to electronic health information through certified health IT. If a health IT developer has a Health IT Module certified to § 170.315(e)(1) or (g)(10) or both, then the health IT developer must submit responses for the number of unique individuals who access electronic health information (EHI) overall and by different methods of access through certified health IT.

(ii) Consolidated clinical document architecture (C-CDA) problems, medications, and allergies reconciliation and incorporation through certified health IT. If a health IT developer has a Health IT Module certified to § 170.315(b)(2), then the health IT developer must submit responses for:

(A) Encounters;

(B) Unique patients with an encounter;

(C) C-CDA documents obtained (unique and overall); and

(D) C-CDA documents reconciled and incorporated both through manual and automated processes.

(iii) Applications supported through certified health IT. If a health IT developer has a Health IT Module certified to § 170.315(g)(10), then the health IT developer must submit responses on how their certified health IT is supporting the application ecosystem, by providing the following information for applications that are connected to their certified health IT including:

(A) Application Name(s);

(B) Application Developer Name(s);

(C) Intended Purpose(s) of Application;

(D) Intended Application User(s); and

(E) Application Status.

(iv) Use of FHIR in apps through certified health IT. If a health IT developer has a Health IT Module certified to § 170.315(g)(10), then the health IT developer must submit responses on the number of requests made to distinct certified health IT deployments that returned FHIR resources, number of distinct certified health IT deployments active at any time, the number of distinct deployments active at any time that returned FHIR resources in response to API calls from apps connected to certified health IT, including stratifying responses by the following:

(A) User type;

(B) FHIR resource; and

(C) US Core Implementation Guide version.

(v) Use of FHIR bulk data access through certified health IT. If a health IT developer has a Health IT Module certified to § 170.315(g)(10), then the health IT developer must submit responses for the total number of FHIR bulk data access requests completed through the certified health IT, and the number of distinct deployments of the certified health IT active at any time overall, and by whether at least one bulk data download request was completed.

(vi) Immunization administrations electronically submitted to immunization information systems through certified health IT. If a health IT developer has a Health IT Module certified to § 170.315(f)(1), then the health IT developer must submit responses for the use of certified health IT to electronically send immunizations administered to immunization information systems (IIS), including stratifying responses based on the following subgroups:

(A) IIS; and

(B) Age group.

(vii) Immunization history and forecasts through certified health IT. If a health IT developer has a Health IT Module certified to § 170.315(f)(1), then the health IT developer must submit responses for the use of certified health IT to query immunization history and forecast information from immunization information systems (IIS), including stratifying responses based on the following subgroup:

(A) IIS.

(B) [Reserved]

(b) Maintenance of Certification. (1) A health IT developer must provide responses to the Insights Condition of Certification specified in paragraph (a) of this section annually for any Health IT Module that has or has had an active certification at any time under the ONC Health IT Certification Program during the prior six months:

(i) A health IT developer must provide responses for measures specified in:

(A) Paragraphs (a)(3)(i), (iii), (iv)(A) and (B), and (vi) of this section beginning July 2027;

(B) Paragraphs (a)(3)(ii)(A) through (C), (iv)(C), (v), (vi)(A) and (B), and (vii) of this section beginning July 2028; and

(C) Paragraph (a)(3)(ii)(D), (vii)(A) of this section beginning July 2029.

(ii) [Reserved]

(2) [Reserved]