This post is for healthtech founders, product heads and sales leads who have been offered a "pilot" by an Indian hospital and are about to say yes without a written plan. It is equally for the hospital-side marketer or innovation lead who has to write the paper that sits behind a pilot.
It answers three questions: what should a hospital pilot be designed to prove, how do you get data access without creating a legal or ethical problem, and how do you argue for the pilot to be paid or at least conditionally converted? It includes a charter template you can copy and a set of exit criteria written as decision rules. Hypothetical numbers are labelled as such. Nothing here is legal or clinical advice; the hospital's legal, clinical and ethics functions must review the real documents.
Why unplanned pilots fail
A pilot that is not designed tends to fail in one of four ways.
- No decision attached. At the end, everyone agrees it "went well", and nobody has the authority or the budget line to convert it. The pilot ends by fading out.
- Success never defined. The vendor measures adoption, the doctor measures time saved, finance measures cost, and nobody agreed which counts.
- Data arrives late or not at all. The hospital's IT team needs weeks to provision access, the pilot window is fixed at 60 days, and half the window is lost.
- Free labour. The vendor's staff do work the hospital's staff would do in a real deployment, so the pilot proves nothing about the steady state.
A charter fixes each of these by making the pilot a small, bounded project with named owners.
The pilot charter
Write the charter as a two- to three-page document, signed by a named hospital sponsor. Use the following fields.
1. Purpose and decision. One sentence on what the pilot will prove, and one on the decision it informs. For example: "To decide whether to deploy the tool across the radiology department."
2. Scope. Which department, which sites, which users, which workflow. State what is out of scope. A pilot in one outpatient clinic does not prove inpatient suitability.
3. Duration and milestones. Start date, go-live date, review dates and end date. Include the time needed for IT access before the clock starts.
4. Roles. A hospital sponsor with budget authority, a clinical lead, an IT lead, an operations contact and a vendor lead. Write names, not titles.
5. Success criteria. Measures with a baseline, a target and a method. See below.
6. Data and access. What data is needed, in what form, who provides it, how it is protected and what happens at the end.
7. Regulatory and ethical position. Whether the pilot is an operational evaluation or research. If it is research, an ethics committee must review it.
8. Commercial terms. Fees, if any, and what the hospital commits to if criteria are met.
9. Exit and conversion. What happens at day one after the pilot ends: stop, extend or convert, and who decides.
10. Reporting. Who gets which report, when, in which format.
Writing success criteria that can be tested
Each criterion needs four parts: a measure, a baseline, a target and a way of measuring. Agree these before the pilot starts and record the baseline from the hospital's own data.
An example using hypothetical figures: a scheduling tool pilot in one outpatient department. The measure is the number of calls per day to the front desk about appointment changes. The baseline is taken over two weeks before go-live from the call log. The target is a reduction the sponsor considers meaningful, agreed in advance. The method is the same call log for the final two weeks of the pilot. The numbers belong to the hospital; the vendor should not claim them elsewhere without written consent.
Mix three types of criteria:
- Outcome measures: the thing the hospital cares about, such as time per task or error rate.
- Adoption measures: how many of the target users actually used the tool, and how often.
- Safety and risk measures: incidents, escalations, complaints, data issues.
Never choose a target that you cannot influence. If the result depends on hospital staff behaviour, state a minimum adoption level as a precondition, so a low result from low use is not read as product failure.
Exit criteria as decision rules
Write the exit rules as if-then statements so nobody argues at the end.
- If the outcome target is met and adoption is above the agreed minimum, the sponsor will begin the conversion process within an agreed number of days.
- If the outcome target is missed but adoption was below the minimum, the pilot extends once, for a defined period, with a named fix.
- If the outcome target is missed with adequate adoption, the pilot ends and the parties record why.
- If a safety or data incident occurs, the pilot pauses until the hospital's responsible officer agrees to restart.
The first rule is the important one. A pilot without an if-then conversion rule is a demonstration.
Data access without trouble
Data is where pilots stall. Plan it from week one.
Minimise. Ask for the least data that lets you test the criteria. If de-identified or aggregated data is enough, say so. Under the Digital Personal Data Protection Rules, 2025, notified on 14 November 2025 with an eighteen-month phased compliance period, the hospital is expected to know why and how personal data is processed. A vendor who asks for more than it needs creates work for the hospital's legal team.
Say who is processor. In most pilots the hospital decides the purpose, and the vendor processes on its behalf. Record that in writing, with security measures, storage location, access controls and deletion at the end.
Separate operational evaluation from research. If the pilot is a research study, including one funded by industry, the Indian medical conduct regulations expect, among other things, permission from the competent authority, clearance from an ethics committee, public disclosure of funding and the freedom to publish results. Those requirements are in clause 6.8.1(e) of the Indian Medical Council (Professional Conduct, Etiquette and Ethics) Regulations, 2002, as amended, which apply to doctors. Ask the hospital's ethics committee secretary early whether the pilot needs review.
Check device status. If your software informs diagnosis or treatment, take regulatory advice on whether the Medical Devices Rules, 2017 apply before the pilot touches live patients.
Plan the access timeline. Request accounts, network access and test environments before the pilot clock starts. Write "pilot day one begins when access is confirmed" into the charter.
