§ 170.403 Communications

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.

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.