For HMIS vendors Product companies
ABDM for HMIS vendors, built once for every customer
Your hospitals are being asked for ABHA at the counter and records in the PHR app, and each one expects your product to deliver it. Build ABDM into the HMIS once, then roll it out site by site without a new project for every customer.
01 The split
What you build once, and what repeats per hospital
The expensive mistake is letting per-site work leak into the product, or product work into every deployment. For what compliance asks of a single system, see HMS and HMIS ABDM integration.
Once, in the product Engineering
- ABHA at registration. Enrolment and login screens, with the consent text, OTP resend timer and ABHA card the test cases look for.
- Publishing records. A hook where OPD notes, prescriptions, lab reports and discharge summaries become care contexts.
- Consent in the consult screen. Raising a request and showing what comes back.
- One webhook handler. Or a polling job, for sites that cannot receive one.
- Certification. Functional testing and the security audit, on the software itself.
Per hospital site Rollout
- An HFR identity. Found or registered, one per physical site — not one for the group.
- Bridge linkage. The site’s HIP and HIU services linked, without which linking calls are rejected.
- A facility in the connector. Activated, so every record carries the right site.
- Configuration, not code. The facility id in that site’s settings, and a credential if it gets its own.
02 Onboarding a site
Adding the next hospital, as API calls
The rollout for a new customer is a sequence your implementation team runs, or your product runs for them.
-
Search HFR before registering
In the Swastik portal’s Facility registry, which also checks for near-duplicates. Many hospitals are already in HFR, and a duplicate entry can only be merged by NHA.
-
Register it, or prove control of it
A new site goes through the portal’s four-step HFR registration. An existing entry is added by its HFR id, and the connector reads the rest from HFR.
-
Link the site to the bridge
Bridge linkage, in the portal. It is the step most often missed: a facility without it authenticates and has every linking call rejected, with no ABDM error naming the cause.
-
Activate, give it a key, map patients
Activate the site and choose it as its application’s hospital. That application’s key then acts for the site — no call names it — and patients are registered by the site’s own MRN, so two customers can both have an MRN-1001.
# set up and linked in the portal; the key reads it
GET /v1/facility
← 200 OK
{
"name": "Sunrise General Hospital",
"hip_id": "IN2710004770",
"status": "active",
…
}
# a key for another site finds nothing here
GET /v1/patients?reference_number=MRN-1001
← 200 OK this site's MRN-1001 only
# that hospital's own MRN, on the key's site
POST /v1/patients
{
"reference_number": "MRN-1001",
"abha_address": "asha.devi@sbx"
}
03 Tenancy
Mapping your customers onto the platform
Three objects decide how customers are separated. Choose the shape before the second customer, not after the tenth.
- Facility
-
One per physical site
Patients, care contexts, consents and records hang off exactly one facility. A hospital group with four buildings is four facilities, and every record released names the one that holds it.
- Application
-
One per integration
An organization can hold several applications, each with its own credentials, scopes and milestone entitlement. Suspending or rotating one leaves the others running.
- Organization
-
The isolation boundary
A credential reaches every facility in its organization. Where customers must never be able to reach each other’s data with one key, give each its own organization; where your cloud HMIS serves them all, one organization with a facility per site is simpler.
- Plan
-
Sized by facilities and applications
The Free plan allows 2 facilities and 2 applications, at 300 requests a minute and 50,000 calls a month, with every milestone. Larger plans raise those limits as your customer count grows.
04 On-premise
Hospitals that run your HMIS on their own servers
Many HMIS installations sit inside a hospital network with no inbound route. ABDM still works there, because nothing has to call in.
- Outbound
-
Every call leaves over HTTPS
The HMIS calls the API; the connector talks to ABDM and receives ABDM’s callbacks on its own public bridge. Nothing is installed on the hospital network and no port is opened.
- Polling
-
Webhooks where you can, polling where you cannot
A site that cannot expose an endpoint reads the same state from the request it made:
GET /v1/link-requests/{link_request_id}for a link,GET /v1/consents/{consent_request_id}for a consent. Your product can support both and pick per installation. - Keys
-
A credential per installation
Issue each on-prem site its own key, allowlisted to that hospital’s egress address. A leaked secret is then usable from one place and revocable without touching any other customer.
05Certification for a vendor
Certification attaches to the software that makes the ABDM calls, so a hospital running your HMIS does not certify separately. What each hospital does need is its own HFR entry per site, linked to that software’s bridge, before its records can move.
The functional testing agency runs ABDM’s test cases, and many have a user-interface half — consent text in the citizen’s language, the resend-OTP timer, the ABHA card, the scan-and-share token at the front desk. The connector is an API, so that half is shown in your HMIS. Build those screens as product features and every customer gets them.
Production also needs this platform’s own approval: a production-access request that a person reviews. The step-by-step view is in the ABDM sandbox guide, and the integration itself in how to integrate ABDM with an HMIS.
06Supporting many hospitals at once
When a hospital calls your support desk because a discharge summary
never reached the PHR app, the answer has to be findable without
asking them for logs. GET /v1/audit/abdm-transactions and
GET /v1/audit/events show that site’s traffic to its
key, and GET /v1/audit/trace/{correlation_id} shows the call,
the ABDM traffic it caused and what happened after.
Failures arrive as events rather than silence:
care_context.link_failed,
health_information.failed, and abdm.error when
an ABDM call fails every retry. Route them to the customer’s
account in your own support tooling. The integration surface itself
is documented in the ABDM API overview.
07How long it takes
The sandbox build is typically 2 to 6 weeks against a connector. Functional testing takes 1 to 2 weeks, the WASA security audit by a CERT-In empanelled auditor 5 to 8 weeks, and NHA review 2 to 4 weeks. The audit is usually the longest stage, and it happens once for the product rather than once per hospital.
After that, each new customer is the site onboarding above. If you also sell to single hospitals building their own integration, the hospital page is the one to send them.
Build it once, against the sandbox
Sandbox keys are issued on email verification. Set up two facilities, link a care context at each, and watch the records stay apart.
FAQ Common questions