Shortlisted™

Home / Blog

A sponsor or vendor wants our patient counts before a contract. What can we share?

A sponsor, a CRO or a data vendor asks how many patients you have who might fit a study. There's no contract yet, sometimes not even a protocol. You want to give a useful answer. But the number comes from your patients' records, and your site is the one answerable for how that information is used.

You can usually give a useful answer without sharing protected health information (PHI). A simple rule: share aggregate counts that can't reasonably be traced back to a patient, label every version, and decide in advance who may pass them on.

This post assumes your site is a HIPAA covered entity, as most practice-based sites are. It is general guidance, not legal advice. Your privacy officer or counsel should confirm what applies to your site, including whether a given report meets one of HIPAA's de-identification methods.

What you can share, and what you can't

Before a contract, keep the answer at the level of counts and rates for a group:

  • Share: how many patients in your records meet the criteria you were able to check, given as a count, a band or a rate.
  • Don't share: names, dates of birth, visit or diagnosis dates, record numbers, addresses, or any patient-level list or file, even with the names removed.

HIPAA recognizes two ways to de-identify information (45 CFR 164.514(b)): Safe Harbor, which removes 18 listed identifiers, including names, record numbers and all date elements except the year, and Expert Determination, where a qualified expert finds the risk of identification very small. A small count can also identify someone when it's paired with a place and a condition. Removing the names isn't enough on its own, and suppression (below) is an extra safeguard, not a substitute for meeting one of those methods.

HIPAA also allows records to be reviewed to prepare for research (45 CFR 164.512(i)(1)(ii)) when the reviewer represents that the review is only for that purpose, that the PHI is needed for it, and that no PHI will be removed from your organization. That internal review produces the count. The count is what you share. If an outside vendor does the review in its own system, that needs a different basis, covered below.

Suppress small counts

A count of three patients with a rare combination of conditions at one clinic can point to a person. That's why some data-use rules suppress small counts. The CMS cell-size policy is one: no count from 1 to 10 may be shown, and no figure may be shown if a 1 to 10 value could be worked out from other figures in the report. Zero may be shown. That policy governs CMS data used under a data use agreement, not your own records, but it's a clear threshold for a site to adopt as its own policy.

In practice:

  • Show any observed count from 1 to 10 as "<11" and add a short note that small counts are suppressed.
  • Check the arithmetic, not just each number in the table. A percentage next to a total, or a subtotal next to a grand total, can give a suppressed number back. If any figure lets someone divide or subtract their way to a suppressed count, change it.
  • Write "<11" the same way on every page.

Use wide bands, and keep them consistent

A band can tell a sponsor what it needs to know (whether your site is worth a closer look) without giving away an exact figure. Make bands wide and rounded from the first draft, so you won't need to change them later.

Changing bands between drafts can undo the protection. If one draft gives a narrow band and a later one widens it but keeps the same lower end, someone who has both can still work back to the narrower figure. Showing a model-based estimate only as an upper bound ("fewer than" a round number) can limit further disclosure, but it can't take back what an earlier draft already showed. Check every new figure against everything the recipient may already have seen.

Two more points about bands:

  • Keep observed counts and estimates apart. If a vendor or analyst projects from a sample to all your patients, label the result as a model-based estimate, say it isn't an enrollment projection, and state the assumptions behind it.
  • Leave the sample size, the sampling fraction and the denominator out of the external report. Anyone who knows or can guess the denominator can divide a small count back out of an extrapolated total. Keep the full method on file internally.

Put a version label on every count

Counts change. Records are updated, and a query run on two different dates can return two different totals for the same definition. When several drafts are in circulation, it's easy to lose track of which number is current, and older drafts may carry figures you later suppressed.

Give every document a short version label with no patient numbers in it. For example:

"Version 2.1, [date]. Changes from v2.0: projection shown as an upper bound only; data source line added. No patient-level data included; counts under 11 suppressed."

Add one line on the data source: which approved query or registry was used, the extract date, and that counts under 11 are suppressed. If the label doesn't suit the final reader, put it in the file name or footer instead. A change log can stay on an internal cover page that never goes to the sponsor.

Decide who may pass the counts on

Agree on this before any work begins, especially when a vendor runs the analysis for you:

  • Your site sees everything first. The vendor sends every draft to you, and nothing goes to a sponsor or CRO until your site approves the final version in writing.
  • Name the recipient. Write down who receives the final version and which pages. Internal cover pages and drafts stay internal.
  • Withdraw old drafts. Mark superseded versions and ask for written confirmation that earlier drafts have been withdrawn and weren't shared outside the two organizations. Withdrawal doesn't erase what someone already saw, which is why the earlier checks matter.
  • Approve the data scope. Say which query or registry the vendor may use and for what purpose, and ask for the date, criteria and count of each query run on your data. A larger dataset you didn't approve for this use shouldn't feed the report, not even as a denominator.
  • Get the data-handling basis in writing before the vendor touches any PHI. A vendor that handles PHI for your site, as your business associate, needs a business associate agreement (BAA) that covers the work. If the vendor works for the sponsor instead, ask your privacy officer which HIPAA basis applies. The report's methods should say who reviewed the records, in what environment, and that only aggregate, suppressed results left it.

Where the CDA fits

A confidentiality agreement (CDA) often governs feasibility discussions, so the sponsor can share the protocol and you can share site information. Depending on its terms, it may protect information in one direction or both, and it limits how the receiving side uses it.

A CDA alone doesn't authorize sharing PHI, and it doesn't replace a BAA with a vendor that handles your records. Before you sign one, read what it says about information your site discloses: who may receive it, whether it can be passed to affiliates or CROs, and how long the obligations last. Then share only aggregate, suppressed counts under it.

Where Shortlisted™ fits

Decisions about what your site shares stay with your team. What we do is help study teams find your site earlier, so the counts you prepare go to studies that fit. Our Trial Radar watches for early signals that a study may need sites and checks each one against what your site can really do. Shortlisted™ is paid only by sites, never by sponsors or CROs. There is no setup fee and no monthly retainer; a fixed fee becomes payable only when a qualified feasibility arrives, and it is never tied to enrollment, patient numbers or study budgets. We don't refer patients or guarantee a place in any study.

Want to see how your site looks to sponsors today? Start with a free Sponsor-Ready Audit.

The short version

Before a contract, share counts, not records. Show any count from 1 to 10 as "<11," use wide bands that stay the same from draft to draft, keep estimates apart from observed counts, put a version label and a data-source line on every document, and approve every draft before it reaches the sponsor. A CDA protects confidential information, but it doesn't authorize sharing PHI, and a vendor that handles your PHI needs its own agreement first.

FAQ

Can a site share patient counts with a sponsor before a contract?

Usually yes, as aggregate counts with no names, dates, record numbers or patient-level files. Show counts from 1 to 10 as "<11," use wide bands, and have your privacy officer confirm the report meets a HIPAA de-identification method.

Why suppress counts under 11?

A small count paired with a location and a condition can point to a person. The CMS cell-size policy, which governs CMS data, doesn't allow counts from 1 to 10 to be shown or worked out from other figures in the same report. A site can adopt the same threshold as its own policy.

Why does a version label matter on a feasibility count?

Counts change as records are updated, and several drafts can end up in circulation. A short label with the version, the date and what changed, with no patient numbers in it, shows everyone which draft is current. Ask for older drafts to be withdrawn.

Does a CDA allow a site to share PHI?

No. A CDA protects confidential business information and limits how it is used. On its own it doesn't authorize sharing PHI, and it doesn't replace a business associate agreement with a vendor that handles your PHI.

What should we agree with a vendor that analyzes our records for our site?

A business associate agreement covering the work, which query or dataset it may use and for what, that every draft comes to your site first, who receives the final version, that old drafts are withdrawn, and a methods line saying who reviewed the records, where, and that only aggregate, suppressed results left that environment.

Request a free Sponsor-Ready Audit More from the blog