Fertility practices hold some of the most personal information in medicine, and they hold it across more systems than most teams realise: an electronic record, a scheduling tool, an embryology or andrology database, a messaging platform, a billing clearinghouse, and usually a spreadsheet somebody built years ago to track cycles. HIPAA is the framework that governs how that information is handled in the United States. What follows is an orientation to the parts that come up most often in reproductive medicine, written for practice managers, coordinators and clinical leads who need to understand the shape of the obligation before they can have a useful conversation about it.
What this article is, and what it is not
This is educational content. It is not legal advice, it is not a compliance program, and it does not create any attorney and client relationship. It is not a substitute for a qualified privacy attorney or compliance professional who knows your practice, your states and your contracts.
HIPAA is a federal framework, state law can be stricter, and regulations change. Where this article says ask counsel, that is not a hedge. Those are the points where a general summary is genuinely not enough to act on.
What counts as protected health information
The scope is wider than the chart
Protected health information, usually shortened to PHI, is individually identifiable health information that your practice creates, receives, maintains or transmits. That includes the obvious clinical material, and it also includes the things people forget: appointment schedules, billing records, voicemails, the sign in sheet, photographs, consent forms, and the message thread where a coordinator walked someone through a medication change.
If a piece of information connects a person to their care, treat it as PHI and let your privacy official tell you otherwise.
Identifiers are what make it identifiable
Information stops being PHI only when it is genuinely de-identified, and the rules set out specific methods for that: stripping a defined list of identifier types, or having a qualified expert determine that the risk of re-identification is very small. Both are more demanding than they sound. Removing names from a spreadsheet that still carries dates of service, postal codes and an uncommon diagnosis has not de-identified anything.
Small populations make this harder, and fertility care is full of them. In a practice running a modest number of donor cycles, a handful of fields can narrow a record to one person.
One record often holds several people
Reproductive medicine complicates the usual assumption of one patient, one chart. A single cycle may involve an intended parent, a partner, a gamete donor, a gestational carrier, and genetic findings that speak to relatives who are not your patients at all. Each of those people has privacy interests of their own, and your consent and authorization paperwork needs to reflect that rather than treat a couple as a single unit by default. This is precisely the sort of question to take to counsel rather than settle by local convention.
The three families of safeguards
The Security Rule organises protections into administrative, physical and technical safeguards. Teams tend to jump to the technical ones because they feel concrete, but most real incidents trace back to administrative gaps: no owner, no training, no process for removing access when someone leaves.
| Safeguard family | What it addresses | What it looks like in a fertility practice |
|---|---|---|
| Administrative | People, policies, oversight and accountability | A named security official, workforce training, a current risk analysis, a sanction policy, incident response, and contingency planning that includes laboratory systems |
| Physical | Buildings, workstations, devices and media | Controlled access to the laboratory and records areas, screens angled away from the waiting room, control of removable media, documented disposal of retired devices |
| Technical | Systems, accounts and the data itself | Unique user accounts, authentication, automatic logoff, audit controls, integrity checks, and encryption at rest and in transit |
Required and addressable are both obligations
Some specifications are described as required and others as addressable. Addressable does not mean optional. It means you assess whether the measure is reasonable and appropriate for your practice, and where it is not, you document that reasoning and put an equivalent alternative in place where doing so is reasonable. The documentation is the step people skip, and it is the step that gets examined later.
Risk analysis is the anchor
Almost everything else follows from an honest, current risk analysis: what information you hold, where it lives, what could go wrong, and what you have done about it. An analysis performed once at go live and never revisited stops describing your practice within about a year, especially if you have added tools since.
Business associate agreements
Who needs one
A business associate is a vendor or partner that creates, receives, maintains or transmits PHI on your behalf. In practice that covers your EMR, scheduling and messaging tools, billing company, transcription or ambient documentation service, cloud hosting, shredding contractor, outsourced IT support, and any patient facing platform that exchanges data with your systems, including tools such as EggWise Pro. If a vendor can reach identifiable patient information, the agreement belongs in place before they do.
Subcontractors count too. Obligations flow downstream, so your vendor's vendors need agreements as well. Ask how that is handled rather than assuming it is.
What the agreement should actually do
- Define what the vendor may and may not do with the information.
- Require appropriate safeguards, and require that subcontractors are bound equivalently.
- Set out how, and how quickly, the vendor notifies you of a security incident or suspected breach.
- Address return or destruction of information when the relationship ends.
- Support your ability to meet patient access and amendment requests.
A signed agreement is not a security assessment. It allocates responsibility; it does not verify competence. Ask separately about encryption, access controls, logging, breach history and where data is physically stored.
Where the gaps usually sit
- Tools nobody approved. A free scheduling app or a personal messaging account adopted by one helpful team member.
- Website analytics and advertising trackers on patient facing pages, which have attracted regulator and litigation attention and deserve a specific review.
- AI, scribe and transcription tools trialled before procurement caught up with them.
- Stale agreements that predate the vendor's current product or hosting arrangement.
- Conduit confusion. The exception for pure conduits of data is narrow. Assume it does not apply to your vendor until counsel says otherwise.
Minimum necessary and role based access
The standard in plain terms
When you use, disclose or request PHI, limit it to what is reasonably needed for the purpose. Recognised exceptions exist, including disclosures for treatment between clinicians, disclosures to the patient, and disclosures the patient has authorised. The standard is not an obstacle to care. It is a limit on browsing.
Build roles around jobs, not titles
Access should follow what someone actually does. Titles drift, people cover for each other, and permissions are almost never taken back. The sketch below is a starting point for a conversation with your clinical and compliance leads, not a template to adopt.
| Role | Usually needs | Usually should not be a default |
|---|---|---|
| Front desk and scheduling | Demographics, appointment times, basic coverage details | Clinical narrative, genetic results, donor identity fields |
| Nursing and coordination | The full clinical record for patients in their care | Records of patients outside their panel or site |
| Embryology and andrology | Cycle and specimen data, plus identifiers needed for witnessing | Billing records and unrelated clinical history |
| Billing | Codes, dates of service, payer information | Free text clinical notes and counselling records |
| IT and system administration | Configuration, accounts and technical logs | Routine clinical record viewing without a logged reason |
| Research and quality improvement | De-identified or limited data as approved | Directly identifiable records without an approved basis |
Break glass and the curiosity problem
Emergency access matters, and so does knowing it was used. Give staff a documented route to information outside their normal scope, and make that route visible and reviewed rather than quietly available.
Most inappropriate access is not malicious. It is looking up a colleague, a neighbour, a relative, or one's own record. In a fertility practice, where a single lookup can reveal a pregnancy, a loss or a donor arrangement, the harm is wildly out of proportion to the curiosity. Say that plainly in training, and say what happens when it occurs.
Joiners, movers and leavers
Most access problems are lifecycle problems. Agree who requests access, who approves it, and who removes it on the day someone changes role or leaves. Review the account list on a fixed schedule and look specifically for shared logins, dormant accounts, and administrator rights nobody remembers granting.
Audit logging
Logging is not the same as reviewing
Systems record activity by default, and that is the easy part. The obligation people underestimate is looking at it. A log nobody opens tells you what happened only after somebody else has told you something happened.
What a useful entry contains
At minimum: which uniquely identified user, which record, what action they took (view, create, amend, print, export), when, and from where. Exports and printing deserve particular attention, because that is the moment information leaves systems you control.
Logs should be protected from alteration by the people whose activity they capture, and retained for a period your policy states and your systems can genuinely honour.
Make review routine and proportionate
- Set a cadence, and give it an owner by name rather than by department.
- Prioritise triggered review: staff and family records, records flagged sensitive, unusually high volume viewing, and access outside normal hours or from unfamiliar locations.
- Investigate patterns rather than single entries, and document what you found and what you did about it.
- Re-check that logging is still enabled after every upgrade, migration or new integration.
Breach notification concepts
Not every incident is a breach
An impermissible use or disclosure of unsecured PHI is presumed to be a breach unless you can demonstrate, through a documented risk assessment, a low probability that the information was compromised. That assessment considers what information was involved and how identifying it was, who used or received it, whether it was actually acquired or viewed, and how far the risk has since been mitigated.
The word documented is doing real work there. A verbal conclusion that it was probably fine is not an assessment.
The clock starts at discovery
Notification timelines run from the point of discovery, not from the point at which your investigation concludes, so a slow internal escalation path spends time you do not have. The regulations set specific outer deadlines and a size threshold above which further notifications apply, including notice to media and contemporaneous notice to the regulator. Those figures are precise, and they are the kind of detail to confirm with counsel rather than with an article. State breach laws can add separate obligations on shorter clocks.
Encryption changes the calculus
Information encrypted to the standard regulators recognise is generally treated as secured, which materially changes what a lost laptop or a stolen phone means for you. Encryption at rest and in transit, across every device that can hold patient information including backup media, is among the highest value technical controls available to a small practice.
Write the plan before you need it
Decide now who is called first, who decides whether to engage counsel, who contacts the vendor, who preserves logs before anything is overwritten, and who is authorised to speak to patients. Walk through it once as a rehearsal. The first hour of a real incident is not when you want to discover that the only person who understands the system is on leave.
Why reproductive health information deserves extra care
The information is unusually revealing
A fertility record can disclose infertility, pregnancy, pregnancy loss, termination, genetic findings, sexual history, donor or surrogacy arrangements, and the structure of someone's relationships, sometimes all in a single line. Many patients have told nobody. Some have told an employer nothing at all, and some have told family a different version.
Patients are actively managing disclosure
Practical consequences follow. Patients have the right to request confidential communications by alternative means or at alternative locations, and in this field that request is common and entirely reasonable. Ask at registration how someone wants to be reached, whether a voicemail is safe, whether the phone is shared, and what may appear on an envelope. Remember that an explanation of benefits sent to a policyholder can disclose care to a partner or parent, and say so early rather than after it happens.
Waiting room habits count as well. Calling a full name and a procedure across a room is a disclosure decision, even when it does not feel like one.
The legal landscape has been moving
Rules touching reproductive health information specifically have been the subject of recent rulemaking and litigation, and the position has shifted more than once. Requests from law enforcement, subpoenas, and questions about disclosure across state lines are exactly the wrong things to work out at the front desk under pressure. Agree in advance that such requests route to counsel before anyone responds, and make sure everyone who answers a phone knows that rule.
Where to start
- Name your privacy official and security official in writing, and make sure staff know who they are.
- Find your most recent risk analysis and read it. If it is missing or stale, that is the first project.
- Inventory every system and vendor that touches patient information, including the ones nobody formally approved.
- Confirm you hold a current signed business associate agreement for each vendor that needs one, and ask each how subcontractors are covered.
- Map roles to permissions, remove standing access nobody uses, and fix the leaver process first.
- Verify audit logging is enabled everywhere it can be, then assign a named owner and a review cadence.
- Put your incident response path on one page and walk the team through it.
- Take your reproductive medicine specific questions to counsel: donor and carrier records, partner access, law enforcement requests, and every state you operate in.
Expect the inventory to be longer than you assumed. That is normal, and finding it is the whole point of doing it.
This article is educational. It is not legal, compliance, billing or coding advice, and it does not reflect the requirements of any particular state. Regulations change, the summaries here are simplified by design, and nothing in them should be relied on as a compliance determination. Confirm your obligations with a qualified privacy attorney or compliance professional who knows your practice, and leave clinical decisions about individual patients with the responsible clinician.