Kōami
Back to Resources
Fertility & IVF7 min read

The ART Act and the Records a Fertility Clinic Has to Keep

K

Kōami

Editorial team

Share this article
The ART Act and the Records a Fertility Clinic Has to Keep — Fertility & IVF | Kōami

The inspection question that catches clinics out is never the difficult one. It is not about culture media or air quality. It is somebody asking to see the consent that a specific couple signed before a specific procedure, on a specific date, in the version that was current at the time. The clinic has the consent. It is in a folder, or a scan named by date, or in a cupboard behind the counter. Producing it takes forty minutes, and the forty minutes is the finding.

India's Assisted Reproductive Technology (Regulation) Act, 2021 and its companion surrogacy legislation moved fertility practice from professional convention to statutory obligation. Most of what the law asks for is not clinically new. What changed is that a clinic now has to be able to prove it, on demand, years later.

What the law is actually asking of a clinic

The specifics belong in the bare Act, the Rules and whatever your state authority has issued, and you should read the current text rather than a summary. But the shape of the obligations is stable, and it is worth being clear about what that shape demands of a record system.

  • Registration. ART clinics and ART banks are registered entities, listed on the national registry, with the level of service they are registered to provide.
  • Reporting. Clinics report cycle-level information to the national registry rather than keeping results as a private matter.
  • Consent. Written, informed consent in the prescribed form from the commissioning couple and, separately, from donors.
  • Donor governance. Donors come through registered ART banks, with screening, and with limits on how donor gametes may be used.
  • Eligibility. Age limits apply to the commissioning couple, and a clinic is expected to have verified them.
  • Records. Retained for a defined period and available to the authority on request.

Nothing in that list is unreasonable. All of it is nearly impossible to satisfy reliably if the underlying record is a mixture of a hospital billing module, a spreadsheet and a stack of scans.

The registry submission is a data problem, not a paperwork problem

Registry reporting is where the gap between a clinic that records structured data and one that does not becomes financial. If cycle type, protocol, age at treatment, number of oocytes retrieved, number fertilised, embryos transferred, and the pregnancy outcome exist as fields, the submission is an export. If any of them lives in free text, in a consultant's notes, or only in the embryologist's day sheet, the submission is a project: three people, two weeks, reconstructing a year from memory and paper.

The reconstruction is where errors enter. Nobody misreports deliberately. They misreport because the only surviving record of what happened on a Thursday in March is ambiguous, and somebody has to make a call under deadline pressure.

A registry return assembled at the deadline reflects what could be found, not what happened. Those are different numbers, and only one of them is defensible.

There is a second-order point that clinics discover late. The export itself should be logged: who ran it, for which period, with what row count, and what was included. When a discrepancy surfaces two years later, the difference between an awkward conversation and a serious one is being able to show exactly what was submitted and when.

Consent, in the only form that survives a challenge

Consent is the obligation that most often exists on paper and fails in practice, and the reasons are mundane.

The form changes. A clinic updates its consent text after legal review, and now there are three versions in circulation. A couple who signed in 2024 signed something different from what the current form says. If the system stores only the current text, the clinic can no longer show what was actually agreed.

The signature is separated from what it covers. A scanned page in a folder proves somebody signed something. It does not prove which procedure it authorised, or that it preceded the procedure.

Withdrawal is not modelled. Consent can be withdrawn, and in ART that withdrawal has immediate consequences for stored material. A system with no concept of withdrawal will happily let a procedure proceed against material the couple no longer consents to.

What a defensible consent record looks like is not complicated: the exact text that was signed, captured as a snapshot rather than a pointer to a document that will later change; each signer identified, with their role and the time; the procedure it covers named; and a withdrawal path that takes effect where it matters, which is at the point the procedure is attempted.

Donors, and the compartment nobody plans for

Donor records carry an obligation ordinary clinical records do not: the identity is confidential, but the screening, the consent and the link to the recipient cycle all have to be provable. Those two requirements pull in opposite directions, and the resolution is access control rather than omission.

In practice that means donor identity sits in its own compartment, with permission to view it granted narrowly and every view logged, while the screening results, the consent status and the linkage remain visible to the people who need to act on them. Clinics that instead handle this by keeping donor details in a separate offline register end up with the worst of both: the identity is less secure, not more, and the linkage is unprovable.

The screening itself has a failure mode worth naming. If the screening form has no mandatory fields on the server side, records get saved with the infection screening blank, because the person filling it in was interrupted and meant to come back. A screening record without a result is not a record of a negative result. It is a record of nothing, and it is indistinguishable from one at inspection.

Retention means the record has to still be readable

Retention periods are the part of compliance that gets agreed in a meeting and then quietly ignored, because the deadline is years away and nothing enforces it. But retention has practical consequences for how the record is built.

  • Data on a workstation's local storage is not retained. Browser storage is not a record; it survives until somebody clears a cache or replaces a machine.
  • Scans on a shared drive with no index are retained but not retrievable, which for an inspection is the same thing.
  • Records that can be silently edited are retained but not trustworthy. If a clinical entry can be changed without a trace, its evidentiary value at year five is close to zero.
  • Signed records need an amendment model. The correct behaviour is an addendum that leaves the original visible, not an overwrite.

The general principle is that a record you can amend without trace is not a record; it is a current opinion about the past.

What to do before the next inspection

If you want a practical sequence rather than a compliance programme, this order works because each step is verifiable on its own.

  • Pick five completed cycles at random and try to assemble the full file for each: consent versions, screening, cycle detail, lab records, witness entries, outcome. Time yourself. The ones that take longest tell you where the record is actually broken.
  • Make the consent snapshot real. Store the text that was signed, not a reference to a document that changes.
  • Make screening fields mandatory where the server writes them, not only in the form.
  • Give every specimen an identity, and make witnessing an event with an authenticated second person.
  • Structure the fields the registry asks for, so the annual return is an export rather than an archaeology project.

None of this is about the law being demanding. The law asks a clinic to be able to show what it did. The clinics that struggle are not the ones practising badly; they are the ones whose records were built to run today's list rather than to answer a question in 2031.

Found this useful? Pass it on to someone on your team.

Share this article