85 FR 25945, May 1, 2020, unless otherwise noted.
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]
[85 FR 25945, May 1, 2020, as amended at 85 FR 70084, Nov. 4, 2020]
(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).
(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).
[85 FR 25945, May 1, 2020, as amended at 85 FR 70084, Nov. 4, 2020; 85 FR 70084, Nov. 4, 2020]
(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.
[85 FR 25945, May 1, 2020, as amended at 85 FR 43711, July 20, 2020; 85 FR 70084, Nov. 4, 2020]
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. A Certified API Developer must publish the service base URLs for all Health IT Modules certified to § 170.315(g)(10) that can be used by patients to access their electronic health information. The Certified API Developer must publicly publish the service base URLs:
(i) For all of its 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; and
(ii) In a machine-readable format at no charge.
(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).
[85 FR 25945, May 1, 2020, as amended at 85 FR 70084, Nov. 4, 2020]
(a) Condition of Certification requirement. A health IT developer with Health IT Module(s) certified to any one or more 2015 Edition certification criteria 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. 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) USCDI Updates. A health IT developer with health IT certified to § 170.315(b)(1), (b)(2), (e)(1), (g)(6) and/or (g)(9) on May 1, 2020, must:
(i) Update their certified health IT to be compliant with the revised versions of these criteria adopted in this final rule; and
(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(3)(i) of this section by December 31, 2022.
(4) C-CDA Companion Guide Updates. A health IT developer with health IT certified to § 170.315(b)(1), (b)(2), (b)(9), (e)(1), (g)(6), and/or (g)(9) prior to May 1, 2020, must:
(i) Update their certified health IT to be compliant with the revised versions of the Program criteria in the 2015 Edition; and
(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(4)(i) of this section by December 31, 2022.
(5) Electronic prescribing. A health IT developer with health IT certified to § 170.315(b)(3) prior to June 30, 2020, must:
(i) Update their certified health IT to be compliant with the revised versions of this criteria adopted in § 170.315(b)(3)(ii); and
(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(5)(i) of this section by December 31, 2022.
(6) Security tags. A health IT developer with health IT certified to § 170.315(b)(7) and/or § 170.315(b)(8) prior to May 1, 2020, must:
(i) Update their certified health IT to be compliant with the revised versions of the criteria adopted in § 170.315(b)(7) and/or the revised versions of the criteria adopted in § 170.315(b)(8); and
(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(6)(i) of this section by December 31, 2022.
(7) ASTM updates. A health IT developer with health IT certified to § 170.315(d)(2), (3), and/or (d)(10) prior to May 1, 2020, must:
(i) Update their certified health IT to be compliant with § 170.210(e)(1) and the standard specified in § 170.210(h); and
(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(7)(i) of this section by December 31, 2022.
(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) Clinical quality measures—report. A health IT developer with health IT certified to § 170.315(c)(3) prior to June 30, 2020, must:
(i) Update their certified health IT to be compliant with the revised versions of this criteria adopted in § 170.315(c)(3); and
(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(10)(i) of this section by December 31, 2022.
[85 FR 25945, May 1, 2020, as amended at 85 FR 43711, July 20, 2020; 85 FR 70084, Nov. 4, 2020; 85 FR 78236, Dec. 4, 2020]
(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
(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]