Certification Companion Guide:
§ 170.403 Communications
Updated on 03-11-2024
This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product certification. The CCG is not a substitute for the requirements outlined in regulation and related ONC final rules. It extracts key portions of ONC final rules’ preambles and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the ONC Regulatory Activities page for links to all ONC final rules or consult other regulatory references as noted. The CCG is for public use and should not be sold or redistributed.
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 | Initial Publication | 06-15-2020 |
| 1.1 | Updated compliance date in regulation text based on correction notice | 08-07-2020 |
| 1.2 | Updated compliance dates per the Interim Final Rule (IFR), Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency. | 11-02-2020 |
| 1.3 | Updated to provide additional clarity on the Attestations Condition and Maintenance of Certification requirements. | 03-12-2021 |
| 1.4 | Updates to reflect changes outlined in Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Final Rule. | 03-11-2024 |
§170.403 Communications.
- Condition of Certification requirements.
- A health IT developer may not prohibit or restrict any communication regarding—
- The usability of its health IT;
- The interoperability of its health IT;
- The security of its health IT;
- Relevant information regarding users’ experiences when using its health IT;
- The business practices of developers of health IT related to exchanging electronic health information; and
- The manner in which a user of the health IT has used such technology.
- 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.
- 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:
- Making a disclosure required by law;
- Communicating information about adverse events, hazards, and other unsafe conditions to government agencies, health care accreditation organizations, and patient safety organizations;
- Communicating information about cybersecurity threats and incidents to government agencies;
- Communicating information about information blocking and other unlawful practices to government agencies; or
- 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.
- 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.
- Developer employees and contractors.
- A health IT developer may prohibit or restrict the communications of the developer’s employees or contractors.
- A self-developer must not prohibit or restrict communications of users of their health IT who are also employees or contractors.
- 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.
- 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.
- Screenshots and video. A health IT developer may require persons who communicate screenshots or video to—
- Not alter the screenshots or video, except to annotate the screenshots or video or resize the screenshots or video;
- 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
- Limit the sharing of video to:
- 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
- Only videos that address temporal matters that cannot be communicated through screenshots or other forms of communication.
- 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.
- Developer employees and contractors.
- 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 health IT developer may not prohibit or restrict any communication regarding—
- Maintenance of Certification requirements.
- 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.
- Contracts and agreements.
- A health IT developer must not establish, renew, or enforce any contract or agreement that contravenes paragraph (a) of this section.
- 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.
- 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.
None.
Attestation Requirements
Outlined below is a summary of the attestation requirements for the Communications Condition and Maintenance of Certification (45 CFR § 170.403). This attestation is a part of the Attestations Condition and Maintenance of Certification requirements and will be available for developers to attest alongside the other attestation requirements in 45 CFR § 170.406 beginning on April 1, 2022, and semiannually thereafter. For additional details related to the attestation requirements please refer to the Attestations Condition and Maintenance of Certification CCG.
- The health IT developer does not prohibit or restrict any communication regarding usability, interoperability, security, user experiences, business practices related to exchanging EHI, and how a user of the health IT used such technology unless such prohibition or restriction was permitted under § 170.403(a)(2)(ii).
- The health IT developer does not prohibit communication of any information whatsoever when the communication is about one or more of the subject matters listed in § 170.403(a)(1) and is made for any of the following purposes:
- Making a disclosure required by law;
- Communicating information about adverse events, hazards, and other unsafe conditions to government agencies, health care accreditation organizations, and patient safety organizations;
- Communicating information about cybersecurity threats and incidents to government agencies;
- Communicating information about information blocking and other unlawful practices to government agencies; or
- 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.
- The health IT developer notifies all customers annually starting in 2021 that any communication or contract/agreement provision that violates the Communications Condition of Certification will not be enforced by the health IT developer.
- The health IT developer notifies all customers annually up to and until the health IT developer amends any contract or agreement that violates the Communications Condition of Certification to remove or void the contravening contractual provisions.
Certification Requirements
Applicability: Applies to all Certified Health IT Developers.
Condition Explanations and Clarifications
Clarifications:
- Developers must not prohibit or restrict communications whether written, oral, electronic, or by any other method if they are protected, unless such prohibition or restriction is otherwise permitted by this Condition of Certification.
- Screenshots and video are considered visual communications and are included in the definition of “communication” for the purposes of the Communications Condition of Certification. However, developers are allowed to place certain limitations on the communication of screenshots and video.
- The Condition of Certification does not impose any limit on the identity of the communicators that are able to benefit from the protection afforded, except that employees, contractors, and consultants of a health IT developer may be treated differently when making communications that are not afforded unqualified protection under § 170.403(a)(2)(i).
- The Condition of Certification applies to developers of health IT certified under the ONC Health IT Certification Program (Certification Program) and to the conduct of such developers with respect to health IT certified under the Certification Program.
- It is not a violation of this Condition of Certification for developers to respond to false or unlawful comments under applicable law, as they do now, and to pursue litigation or any other available legal remedy in response to any protected communications that are covered by this Condition of Certification.
- The Condition of Certification applies to both formal prohibitions or restrictions and those that arise by way of the developers’ conduct. However, the conduct in question must have some nexus to the making of a protected communication or an attempted or contemplated protected communication.
- The Communications Condition of Certification provides protections against retaliation and intimidation by developers with respect to protected communications.
- As of June 30, 2020, contravening provisions in contracts or agreements cannot be enforced without the risk of losing certification for the developer’s health IT under the Certification Program, regardless of whether the customer was notified as required by this Condition of Certification.
Clarifications:
- The factors of usability that are the subject of protected communications include but are not limited to, the following: the user interface (e.g., what a user sees on the screen, such as layout, controls, graphics, and navigational elements); ease of use (e.g., how many clicks); how the technology supports users’ workflows; the organization of information; cognitive burden; cognitive support; error tolerance; clinical decision support; alerts; error handling; customizability; use of templates; mandatory data elements; the use of text fields; and customer support.
- Communications about the usability of health IT may include communications about features that are part of the health IT product as well as communications about what is not in the health IT product.
Clarifications:
- Interoperability is defined as
- (10) INTEROPERABILITY.—The term ‘interoperability’, with respect to health information technology, means such health information technology that—
- ‘‘(A) enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user;
- ‘‘(B) allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable State or Federal law; and
- ‘‘(C) does not constitute information blocking as defined in section 3022(a).’’
- Protected communications regarding the “interoperability of health IT” would include communications about whether a health IT product and associated developer business practices meet the interoperability definition described in section 3000(9) of the PHSA, including communications about aspects of the technology or developer that fall short of the expectations found in that definition. This includes communications about the interoperability capabilities of health IT and the practices of a health IT developer that may inhibit the access, exchange, or use of EHI, including information blocking.
- (10) INTEROPERABILITY.—The term ‘interoperability’, with respect to health information technology, means such health information technology that—
Clarifications:
Health IT security is broadly construed to include any safeguards, whether required by the HIPAA Security Rule or not, that may be implemented (or not implemented) by a developer to ensure the confidentiality, integrity, and availability of electronic health information (EHI) (information that includes electronic protected health information (ePHI)), together with the health IT product’s performance regarding security.
Clarifications:
- To qualify as a “user experience,” the experience must be one that is had by a user of health IT. This includes communications and information about a person or organization’s experience acquiring, implementing, using, or otherwise interacting with health IT. This includes experiences associated with the use of health IT in the delivery of health care, together with administrative functions performed using health IT. User experiences would also include the experiences associated with configuring and using the technology throughout implementation, training, and in practice. Further, user experiences would include patients’ and consumers’ user experiences with consumer apps, patient portals, and other consumer-facing technologies of the health IT developer.
- A “relevant user experience” includes any aspect of the health IT user experience that could positively or negatively impact the effectiveness or performance of the health IT.
Clarifications:
- Protected communications are broadly construed to include developer policies and practices that facilitate the exchange of EHI, and developer policies and practices that impact the ability of health IT to exchange health information. The protected communications include, but are not limited to:
- the costs charged by a developer for products or services that support the exchange of EHI (e.g., interface costs, API licensing fees and royalties, maintenance and subscription fees, transaction or usage-based costs for exchanging information);
- the timeframes and terms on which developers will or will not enable connections and facilitate exchange with other technologies, individuals, or entities, including other health IT developers, exchanges, and networks;
- the developer’s approach to participation in health information exchanges and/or networks;
- the developer’s licensing practices and terms as it relates to making available APIs and other aspects of its technology that enable the development and deployment of interoperable products and services;
- the developer’s approach to creating interfaces with third-party products or services, including whether connections are treated as “one off” customizations, or whether similar types of connections can be implemented at a reduced cost; and
- information about switching costs imposed by a developer.
- The Condition of Certification only applies to business practices regarding certified health IT related to the exchange of EHI, and not to business practices regarding other health IT products of a developer that are not certified under the Certification Program.
Clarifications:
- Protected communications regarding the “manner in which a user has used health IT” would encompass any information related to how the health IT has been used and is not limited to uses that involve direct patient care. The types of information that fall within this subject area include but are not limited to:
- information about a workaround implemented to overcome an issue in the health IT;
- customizations built on top of core health IT functionality;
- the specific conditions under which a user used the health IT, such as information about constraints imposed on health IT functionality due to implementation decisions; and
- information about the ways in which health IT could not be used or did not function as was represented by the developer.
Clarifications:
- “Developer employees and contractors” include health IT developer employees, together with the entities and individuals that are contracted by health IT developers to deliver products and/or services who may be exposed to highly sensitive, proprietary, and valuable information in the course of performing their duties.
- The limited prohibitions developers may place on their employees or contractors under the Communications Condition of Certification requirements cannot be placed on users of a self-developer’s certified health IT who are also employees or contractors of the self-developer.
- The concept of “self-developed” refers to a Complete EHR or Health IT Module designed, created, or modified by an entity that assumed the total costs for testing and certification and that will be the primary user of the health IT (see also 76 FR 1300).
Clarifications:
- A “user-facing aspect of health IT” means those aspects of health IT that are disclosed and evident to anyone running, using, or observing the operation of health IT. That is, user-facing aspects of health IT comprise those aspects of the health IT that are manifest in how the health IT software functions and would be apparent to someone interacting with the health IT as a user of the health IT.
- “Non-user-facing aspect of health IT,” for the purpose of this Condition of Certification, comprises those aspects of the health IT that are not readily apparent to someone interacting with the health IT as a user of the health IT. This could include, for example, source and object code, software documentation, design specifications, flowcharts, and file and data formats, as well as algorithms and underlying software utilized by the health IT in the background, and not directly by a user of the health IT.
- Screenshots or videos depicting source code would be considered communications of non-user-facing aspects of health IT and could be restricted under the Communications Condition of Certification requirements as long as they did not receive unqualified protection.
Clarifications:
- Developers and ONC will apply a fair use test to copyrighted materials (and materials that could be copyrighted) to determine whether developers may prohibit a communication that would infringe on intellectual property (IP) rights.
- This Condition does not prohibit developers from enforcing their IP rights, and a lawsuit filed by a developer in response to a protected communication regarding infringement of IP rights would not automatically be considered intimidation or retaliation in violation of this Condition.
Clarifications:
- The number of screenshots or the amount of video that would be needed to communicate about the health IT could vary, from one situation to the next, based on the specific issue and circumstances.
- An issue with health IT functionality regarding a particular process that involves the user viewing and making selections on several different screens may necessitate images of all of the screens involved to communicate the issue. However, an issue regarding how one value is being displayed in a particular context (e.g., a medication name being truncated) may only necessitate one screenshot to communicate the issue.
- A video meant to communicate a delay (e.g., in order entry) would need to be long enough to communicate the significance of the delay, but would not need to include video of the log-in process or other unrelated functionality of the health IT.
Clarifications:
- No additional clarifications.
Clarifications:
- No additional clarifications.