Connecting a hospital or health-tech product to ABDM is rarely blocked by the APIs themselves. It is blocked by things nobody scoped: a legacy system with no structured data, unclear consent handling, or a vendor who has never passed ABDM certification. This checklist is for hospital IT heads, product owners and CTOs in healthcare who want to know, before spending budget, whether they are actually ready.

Tick what is true today. Every unticked item is a line in your project plan.

Before you start: scope and ownership

  • [ ] We have decided which role we are integrating as: Health Information Provider (HIP), Health Information User (HIU), or both
  • [ ] We know which ABDM milestones apply to us (ABHA creation and verification, sharing health records, consuming records) and in what order
  • [ ] One named owner (not a committee) is accountable for the ABDM programme
  • [ ] We have confirmed current registration steps, sandbox access and certification requirements directly from the official ABDM documentation, not from a vendor deck
  • [ ] Clinical, IT, front-desk and compliance leads have agreed what success looks like (for example, ABHA created at registration, discharge summaries linkable)
  • [ ] We have a budget line for certification, testing and post-go-live support, not just development

Current-state assessment

  • [ ] We have listed every system that holds patient data: hospital information system (HIS/EMR), LIS, RIS/PACS, pharmacy, billing, telemedicine
  • [ ] We know which of these can export structured data and which only produce PDFs or scans
  • [ ] Patient identifiers are consistent across systems, or a master patient index exists
  • [ ] We know how many records are structured vs. free-text vs. scanned
  • [ ] We have documented which departments will go live first (usually OPD, then IPD/discharge)
  • [ ] Our HIS vendor has confirmed in writing whether they support ABDM, and at which milestone

Technical requirements

  • [ ] We can produce clinical documents in the FHIR format ABDM expects (for example, prescriptions, diagnostic reports, discharge summaries)
  • [ ] Where the vendor cannot deliver, custom software or an API layer is planned. An integration engine exists between the HIS and the outside world
  • [ ] We have a sandbox environment separate from production
  • [ ] Callback endpoints are publicly reachable over HTTPS with valid certificates
  • [ ] Logging captures every request, consent and data transfer with timestamps
  • [ ] We have a plan for retries and failure handling when the gateway is slow or down
  • [ ] Time sync, uptime monitoring and alerting are in place for the integration service

ABHA and registration workflow

  • [ ] Front-desk staff can create or look up an ABHA at registration without leaving the HIS
  • [ ] We have a fallback for patients who have no phone or Aadhaar-linked number
  • [ ] ABHA addresses are stored and validated, and mismatches are flagged
  • [ ] Staff have been trained on what to tell patients about why ABHA is being requested
  • [ ] Patients can see and understand what is being linked to their ABHA
  • [ ] Consent requests are handled through the ABDM consent flow, never bypassed internally
  • [ ] We record purpose, data types, validity period and revocation status for each consent
  • [ ] Access to patient data in our systems is role-based and audited
  • [ ] Data is encrypted in transit and at rest
  • [ ] We have mapped our obligations under India's data protection law and our own retention policy to the integration (confirm specifics with counsel)
  • [ ] A breach-response plan exists and names who calls whom
  • [ ] A security review or penetration test is scheduled before go-live

Vendor evaluation: questions to ask before you sign

QuestionWhat a good answer looks like
Which ABDM milestones have you completed in production?Named hospitals or products and dates you can verify
Who owns certification?A named vendor team, with the process and timeline written into the contract
How do you handle FHIR bundles from our legacy modules?A mapping plan per document type, not "we support FHIR"
What happens when ABDM specs change?Change handling and cost covered in the support agreement
Where does the integration run and who has access?Clear hosting, access control and audit answers
What is excluded from the quote?A short, explicit list

Red flags

  1. "We are ABDM compliant" with no milestone, date or reference.
  2. No sandbox testing plan, only a go-live date.
  3. Consent handled "inside our system" instead of through the ABDM flow.
  4. Scanned PDFs proposed as the plan for structured records.
  5. No owner on the hospital side.
  6. Fixed price with no assumption about the number of document types.

Go-live readiness

  • [ ] End-to-end test passed in sandbox: ABHA creation, linking, consent, data transfer
  • [ ] Certification steps completed and evidence stored
  • [ ] Staff trained and a one-page SOP at every registration desk
  • [ ] Pilot department selected with a rollback plan
  • [ ] Support rota defined for the first two weeks
  • [ ] Metrics agreed: ABHAs created, records linked, failed transfers, time added to registration

How to use this

Run through the list, and turn the gaps into an integration roadmap, with your HIS vendor, your clinical lead and whoever owns compliance in the same room. Count the unticked boxes per section; the section with the most gaps is where your first month of work goes. Share the vendor table with every bidder and compare answers side by side.

Next step

If you would like to run this checklist against your own hospital or product, we can walk through it together in 30 minutes and flag the gaps that matter most. Book a 30-minute call