Marketing EHR and health IT software to practices: certification claims, fees and information blocking

An EHR, practice management system or patient engagement platform is sold to a practice owner who is about to trust it with every chart, claim and patient message the practice has. Marketing that software is B2B marketing, but federal health IT rules reach into it in ways a general software playbook does not cover. If a product is certified under the ONC Health IT Certification Program, a federal regulation says what must appear in every marketing piece that mentions the certification. If the developer has certified health IT, the information blocking rules apply to how it handles data access, export and fees, which are the same subjects sales pages make promises about.

This guide is for founders and marketing leads at health IT companies that sell to independent practices, and for practice owners who want to read vendor marketing with a sharper eye. It covers certification claims, required disclosures, pricing, data access promises, customer reviews and screenshots, and how to describe your HIPAA role. Some topics have their own guides, and we link to them instead of repeating them: consumer health apps and the FTC, what makes a vendor a business associate, billing company claims and client case studies, and medical device marketing claims. LinkedIn ads, employee posts and customer case studies are covered in our guide to LinkedIn marketing for healthcare companies.

What “certified” means, and what it does not

The ONC Health IT Certification Program is voluntary. The information blocking regulation describes it as “a program for the voluntary certification of health information technology that is kept or recognized by the National Coordinator” (45 CFR 171.102). Certification is issued to a Health IT Module against specific certification criteria, by an ONC-Authorized Certification Body (ONC-ACB). Certified modules are listed publicly on the Certified Health IT Product List (CHPL), where a buyer can look up the developer, product, version, certification date, certification number and the criteria the module was certified to.

That structure shapes how the word can be used. A certification belongs to a specific module and version, for specific criteria. It is not a rating of the whole company, and it is not a general seal of quality. So the honest claims are narrow ones:

• “Version 9 of our clinical module is certified under the ONC Health IT Certification Program” is checkable on the CHPL, if it is true.
• “ONC certified EHR” on a homepage, when only one module of a larger suite is certified, overstates what was certified.
• “Government approved” or “endorsed by HHS” is wrong on its face: the required disclaimer, quoted below, says certification “does not represent an endorsement by the U.S. Department of Health and Human Services.”
• A claim about a version that has since been replaced should be updated when the listing changes.

Under 45 CFR 170.523(k)(4), a certification based solely on the program’s criteria “must be separate and distinct from any other certification(s) based on other criteria or requirements.” If you also hold a private security or industry certification, present it separately so a reader does not take it for part of the federal program.

The disclosures 170.523(k) requires in every marketing piece

Section 170.523 sets the rules of conduct for certification bodies, and paragraph (k) tells them to ensure developers follow mandatory disclosures. The text is direct: “A health IT developer must conspicuously include the following on its website and in all marketing materials, communications statements, and other assertions related to the Health IT Module’s certification.” That reaches product pages, brochures, sales decks, trade show material and press releases that mention the certification.

Three items are required. The first is this disclaimer, word for word:

“This Health IT Module is compliant with the ONC Certification Criteria for Health IT and has been certified by an ONC-ACB in accordance with the applicable certification criteria adopted by the Secretary of Health and Human Services. This certification does not represent an endorsement by the U.S. Department of Health and Human Services.”

The second is the listing information named in 170.523(f)(1), as applicable to the module: the developer name, product name and version, developer contact details, the date the module was certified, the unique certification number, the certification criteria it was certified to, the clinical quality measures it was certified to where applicable, and any additional software the module relied on to demonstrate compliance with a criterion. The third is a plain language description of additional costs, covered in the next section.

In practice, a vendor can keep one certification disclosure page per module with all of this information, and link to it from every page, deck and document that mentions certification. The word “conspicuously” in the rule matters: a disclosure buried in a footer link labeled “legal” is harder to defend than a clear link next to the claim itself. Under 170.523(f)(1)(xx), the certification body’s own listing must include a hyperlink to these disclosures, so the page should stay at a stable address.

Cost transparency: the price page is part of the disclosure

Under 170.523(k)(1)(iii), the developer must describe “in plain language, a detailed description of all known material information concerning additional types of costs or fees that a user may be required to pay to implement or use the Health IT Module’s capabilities.” The rule lists the kinds of costs it means: fees “whether fixed, recurring, transaction-based, or otherwise” to “purchase, license, implement, maintain, upgrade, use, or otherwise enable and support the use of capabilities to which health IT is certified,” including fees charged by third parties the developer obtains technology or services from, and fees “in connection with any data generated in the course of using any capability to which health IT is certified.” Health IT self-developers are excluded from this paragraph under 170.523(k)(1)(v).

For a sales page, that means the headline price cannot be the whole story when other fees are part of using the certified capabilities. A practice owner should be able to find, in plain words, what they will pay for:

• Implementation, data migration and training.
• Interfaces to labs, imaging, pharmacies or health information exchanges, including any per-interface or per-transaction fees.
• Upgrades needed to keep a certified capability working.
• Patient portal, API access or reporting capabilities that the certification covers.
• Any third-party component the certified capability relies on.
• Exporting data, including when the practice leaves.

Section 5 of the FTC Act, 15 U.S.C. 45, separately prohibits unfair or deceptive acts or practices “in or affecting commerce,” and it is not limited to ads aimed at individual consumers. A per-provider price that omits mandatory fees can mislead a practice the same way it would mislead anyone else.

The certification mark

Certification bodies must display the ONC Certified Health IT Certification and Design Mark on certifications they issue, and must “ensure that use of the mark by health IT developers whose products are certified under the ONC Health IT Certification Program is compliant with the Criteria and Terms of Use” for the mark (45 CFR 170.523(l)). If you use the mark, read the current terms of use from ASTP/ONC or your certification body first, use it only next to the certified module it belongs to, and do not alter it or attach it to products or versions that are not certified.

Information blocking: your data promises are regulated conduct

If your company has at least one certified Health IT Module, it is a “health IT developer of certified health IT” under 45 CFR 171.102, which makes it an “actor” under the information blocking regulation. For developers, information blocking is a practice that, unless required by law or covered by an exception, “is likely to interfere with access, exchange, or use of electronic health information,” where the developer “knows, or should know” that it is likely to do so (171.103). “Interfere” is defined to mean “to prevent, materially discourage, or otherwise inhibit.” The ban is also a condition of certification: under 170.401, a developer “must not take any action that constitutes information blocking.”

The stakes are set by statute. Under 42 U.S.C. 300jj-52(b)(2)(A), a developer, network or exchange that the HHS Office of Inspector General determines has committed information blocking is subject to a civil money penalty that “may not exceed $1,000,000 per violation.” The OIG information blocking page says the same. Under 171.1101(b), ONC will post on its public website information about developers that the OIG has determined committed information blocking, including the developer’s legal name.

Marketing touches this in two directions. First, what you promise has to match what you do. Lines like “your data is always yours” or “switch anytime, no lock-in” are claims a practice will test the day it asks for a full export. Second, what you charge for data access has rules. The fees exception in 171.302 sets conditions for fees to count as an exception, and under 171.302(b) the exception does not apply to, among others:

• “A fee to perform an export of electronic health information via the capability of health IT certified to § 170.315(b)(10) of this subchapter for the purposes of switching health IT or to provide patients their electronic health information.”
• “A fee to export or convert data from an EHR technology that was not agreed to in writing at the time the technology was acquired.”

So an export fee that first appears when a practice gives notice is a legal question, not only a customer service one. If your contract does set export or conversion fees, disclose them in writing up front, describe them in your 170.523(k) cost disclosure and have counsel review them against 171.302 before a price page goes live. The exceptions in subparts B, C and D of Part 171 are detailed, and whether a practice fits one is a question for counsel, not for marketing copy.

Practices are actors too. A health care provider engages in information blocking under 171.103(b)(2) when it “knows that such practice is unreasonable and is likely to interfere with access, exchange, or use of electronic health information.” Under 42 U.S.C. 300jj-52(b)(2)(B), providers found to have done so are referred for “appropriate disincentives,” which the regulation sets out in subpart J of Part 171. Vendors that help practices meet these obligations can say so, but describe the features, not a promise of compliance.

Customer contracts, reviews, screenshots and gag clauses

Here the federal rules cut against a familiar sales and legal habit. Under 45 CFR 170.403(a)(1), a developer of certified health IT “may not prohibit or restrict any communication regarding” six subjects:

• 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.
• The manner in which a user of the health IT has used such technology.

Certain communications, such as reports to government agencies about safety, cybersecurity or information blocking, get “unqualified protection” under 170.403(a)(2)(i). Other restrictions are permitted only as the rule lists them, such as limits on the developer’s own employees and contractors, non-user-facing aspects of the software, intellectual property restrictions “no broader than necessary,” and limited conditions on screenshots and video. Under 170.403(b)(2)(i), a developer “must not establish, renew, or enforce any contract or agreement that contravenes” these requirements.

For marketing and customer success teams, that means:

1. No review suppression in contracts. A clause that bars a customer from posting a negative review about usability or interoperability is the kind of restriction 170.403 prohibits. Remove it from order forms, terms of service and reference agreements.
2. Screenshots are allowed, within limits. Under 170.403(a)(2)(ii)(D), you may require that customers not alter screenshots or video except to annotate or resize them, and that they share only the amount needed to communicate about the subjects listed above. You may not ban them outright.
3. Reference customers speak freely. A customer who agrees to be a reference can still speak about the six subjects on their own terms, including critically.

Customer quotes and logos in your marketing are endorsements under the FTC Endorsement Guides, 16 CFR Part 255. Our guide to billing company marketing walks through how the Guides apply to client testimonials, logos and referral credits when the buyer is a practice, and the same analysis carries over to software.

Security, uptime, interoperability and efficiency claims

The FTC Policy Statement Regarding Advertising Substantiation (November 23, 1984) says advertisers must have a reasonable basis for objective claims before they are made. The claims below are objective ones, so each needs that basis:

• Uptime. State the figure as your contract defines it, the period it covers and what counts as downtime, and keep the monitoring records.
• Security. Describe specific controls you actually run, such as encryption, multi-factor authentication or access logging. Avoid absolute claims like “unhackable” or “bank-level security” that you cannot define or prove.
• Interoperability. Name the standards and connection types you support, and say which ones are part of a certified capability. “Connects to everything” is not a claim a buyer can test.
• Time saved. A claim that clinicians save a set number of minutes per visit needs a documented study of your product, with its method and setting stated. Without one, describe the workflow instead.
• AI features. Say what the feature does and where a person reviews its output. Our guide to AI and healthcare marketing claims covers the claim side in more depth.

If your product has functions that may raise FDA medical device questions, such as clinical decision support, those claims have their own set of rules, which our guide to medical device marketing claims covers.

Your HIPAA role, described in terms a buyer can check

Under 45 CFR 160.103, a business associate is a person who, on behalf of a covered entity, “creates, receives, maintains, or transmits protected health information” for a regulated function or activity. A vendor that hosts a practice’s records, processes its claims or sends its patient messages fits that description. Under 164.502(a)(3), a business associate “may use or disclose protected health information only as permitted or required by its business associate contract” or as required by law.

We advise against badges and phrases like “HIPAA certified” or “fully compliant.” A practice cannot verify a label, and compliance depends on how you operate, not on a label. Say what a practice can verify instead: that you enter into a business associate agreement with each customer before receiving patient information, if that is true, how access is controlled and logged, where data is hosted, and who is responsible for privacy and security. The phrase “built with HIPAA in mind” describes intent without promising an outcome. Our guide to business associate agreements covers what those agreements contain.

Demos, case studies and customer data

Demo environments, screenshots in ads and recorded walkthroughs should use synthetic records, never real patients. Showing a real patient’s chart in a demo or an ad discloses that patient’s information.

A case study built from a customer’s data has two questions to answer first. Does your business associate agreement allow the use? And is the data de-identified? Under 164.502(d)(2), information de-identified under 164.514(a) and (b) is not individually identifiable health information. Aggregated, practice-level figures with written customer permission are the safer route. The customer’s own name and logo need permission too, since they reveal a business relationship the practice may not want public.

Illustration: rewriting an EHR product page

Illustration. A product page for a small-practice EHR reads “The ONC certified, HHS approved EHR. HIPAA certified. Switch anytime, free.” Below the headline are a price of a flat monthly fee per provider, a quote from a clinic saying charting time was cut in half, a screenshot of a chart with a real patient name, and a footer link labeled “legal.” The customer agreement includes a clause barring customers from “disparaging the software in any public forum.” Here is how the page and contract change:

1. Certification claim. The headline now names the certified module and version. “HHS approved” comes out. Next to the claim is a link to a certification disclosure page with the required disclaimer, the CHPL listing details and the cost disclosure.
2. Price. The flat fee stays, with a plain list of implementation, interface, migration and export fees beside it, and the same list on the disclosure page.
3. Switching. “Free” is checked against the contract. If any export or conversion fee applies, the page says so, and counsel reviews it against 171.302.
4. HIPAA badge. Removed. A short section says the company enters into a business associate agreement with each practice before receiving patient information and names the role responsible for privacy and security.
5. Quote. The charting time quote stays only with support and a statement of what customers generally experience, measured the same way. Otherwise it is replaced with a quote about onboarding or support.
6. Screenshot. Replaced with one built on synthetic records.
7. Contract. The non-disparagement clause is removed from new and renewing agreements, as 170.403(b)(2)(i) requires.

Checklist

• Every certification claim names the certified module and version, and matches the CHPL listing.
• No “government approved” or “endorsed by HHS” language.
• A certification disclosure page with the exact 170.523(k)(1)(i) disclaimer and the required listing information, linked conspicuously wherever certification is mentioned.
• Plain language description of all known material additional costs, including third-party and data-related fees.
• Other certifications presented separately from the ONC program.
• Certification mark used only under its current terms of use, and only for the certified module.
• Data access and switching promises match the contract, and export fees reviewed against 171.302.
• No contract terms restricting communications about usability, interoperability, security, user experiences, data exchange practices or use of the product.
• Uptime, security, interoperability and time-saved claims backed by records, with the measure stated.
• No “HIPAA certified” or “fully compliant” badges; business associate role described in checkable terms.
• Synthetic data in demos, ads and screenshots.
• Customer data, names and logos used only with written permission and as the business associate agreement allows.

How we help

We build websites, local search, Google Ads and AI front desk tools for independent practices, and the same work applies to companies that sell software to them. For a health IT vendor, that means a website with product, pricing and certification disclosure pages that make claims you can document, search pages that answer the questions practice owners ask, and ads that point to pages saying the same thing. Our own tools are built with HIPAA in mind. We confirm in writing what a BAA covers before any patient information flows through a tool, and if it is not covered, we do not route patient information through it.

Sources

• 45 CFR 170.523: Principles of proper conduct for ONC-ACBs
• 45 CFR 170.401: Information blocking (Condition of Certification)
• 45 CFR 170.403: Communications
• 45 CFR Part 171: Information Blocking (171.101, 171.102, 171.103, 171.302, 171.1101)
• 42 U.S.C. 300jj-52: Information blocking
• HHS OIG: Information Blocking
• ASTP/ONC: Certification of Health IT
• Certified Health IT Product List (CHPL)
• 45 CFR 160.103: Definitions
• 45 CFR 164.502: Uses and disclosures of protected health information, general rules
• 15 U.S.C. 45: Unfair methods of competition unlawful
• FTC: Policy Statement Regarding Advertising Substantiation (November 23, 1984)
• 16 CFR Part 255: Guides Concerning the Use of Endorsements and Testimonials in Advertising

More in Health companies, vendors and employers