01Step 0: the facility manager
HFR does not accept a registration from a piece of software. It accepts one from a person, identified by an HPR ID whose category is Facility Manager, and every API call in the registration carries that person’s HPR token. So before any facility detail is entered, the manager either signs in to HPR with an OTP or creates a facility manager HPR ID with Aadhaar.
Two things about that ID are worth knowing. It is created in HPR’s administrative category, code 100, sub-category 85, and a person can hold only one HPR ID per Aadhaar, so a doctor who also manages the hospital has to decide which the ID is for. The HPR guide covers the categories.
02Step 1: basic information
The first call creates a draft and returns a tracking id that the next three steps quote. Sending the step again with the tracking id updates the draft; without it, HFR opens a second draft and, if the name, type and coordinates match the first, refuses it as a duplicate. Keep the tracking id.
What HFR requires here, from experience against its sandbox:
- Facility name, ownership and ownership sub-type, from HFR’s masters.
- Systems of medicine, facility type and facility sub-type. The type list depends on the first system of medicine chosen; the sub-type list depends on the type, and some types list none, in which case HFR still requires a code.
- State, district and sub-district as LGD codes, region, address, and a six-digit PIN.
- Latitude and longitude, one to six decimal places. HFR refuses a draft without them.
- A board photo and a building photo, base64, with file names in HFR’s format: letters, digits and a few symbols, then
.jpg,.jpeg,.pngor.pdf. - Address proof, optional: a type from the ADDRESS-PROOF master, such as an electricity bill, rent agreement or title deed, with the document attached.
- Contact number and email, working days and hours.
03Steps 2 and 3: services and details
Additional information covers what the facility offers: whether it has a pharmacy, blood bank, dialysis or a catheterisation laboratory, and the specialities under each system of medicine. Detailed information covers beds, staff counts, equipment, imaging and diagnostic services. Each section is optional or mandatory depending on what was declared in the step before, so the three steps have to be kept in order.
04Step 4: submit
Submit is the one call that creates the HFR entry. It takes the tracking id and, optionally, a source of information: the registry the facility is already known to, as a code from HFR’s SOURCE master, with the facility’s id there. State HMIS ids, AB-PMJAY empanelment, NIN, e-Hospital, CoWIN and NIKSHAY are among the sources. Any other text is refused as “Source Of Information value is invalid”; a facility in none of them leaves it blank and is registered as a submitted entity.
HFR answers either with the facility id at once, an IN
followed by digits, or with a message that the registration is under
review, in which case the id follows later and has to be watched for.
05Step 5: bridge linkage
This is the step most integrations miss, and the hardest to diagnose when it is missed. A facility id authenticates perfectly well against ABDM’s gateway and has every linking, consent and subscription call refused, because the gateway does not know which software serves it. The facility’s HIP and HIU services must be registered against your software’s bridge, through HFR’s bridge-services API.
Three things to know about that call. It answers HTTP 200 whatever happened and puts the verdict per service in the body, so success has to be read from the body. A facility registered through your own software, with the manager’s HPR token, may come back “already associated”, because HFR attached the bridge at registration; that is success. And a facility whose linkage was merely declared, rather than confirmed by ABDM, is not linked at all, however green the dashboard looks.
You can check what ABDM actually holds: the gateway’s bridge-services listing returns every service registered against your bridge, with its types. If the facility is not in it, nothing else will work.
06Refusals HFR does not explain
- “Source Of Information value is invalid”: the field is a SOURCE master code, or blank.
- “Facility Address Proof attachment name is invalid”: the file name has spaces or characters outside HFR’s set; rename it.
- “Duplicate facility found for same Facility Type, Geolocation and Facility Name”: a draft with these details already exists, most often your own; continue it with its tracking id instead of creating another.
- “Invalid Facility SubType code”: the code is not one HFR holds for the type, even when it lists none. Try HFR’s general codes, then the closest other type.
- “Dependent Service Unavailable” on any later ABDM call: the bridge linkage above is missing.
The connector checks each of these before sending, where it can, and otherwise turns the answer into the sentence above with the field to look at. See HFR integration.
07A facility already in HFR
Registration is only for a facility HFR has never seen. A hospital that already has an id is added by that id: the connector reads its record from HFR, prefills name, type and address, and goes straight to the bridge linkage. Registering it again creates a duplicate that only NHA can merge, so search first. HFR’s search finds registered facilities; it does not find drafts, which is why a duplicate check can say nothing while a draft of your own blocks the save.