abdm-m4-nhpr

name	abdm-m4-nhpr
description	Integrate ABDM Milestone 4 - HPR ID creation for healthcare professionals, HFR facility search/onboarding/linking, software linkage via Eka Bridge, and facility onboarding to Eka. Use when the user says "integrate M4", "HPR", "HFR", "register doctor", "onboard facility", "NHPR", "bridge linkage", or is setting up providers before go-live.

M4 — HPR & HFR Registration + Onboarding

M4 is mostly one-time setup per professional/facility, but HMIS/LMIS products should embed it so new doctors/facilities self-onboard.

HPR (professionals)

• First-time registration (Aadhaar): get-aadhar-otp → verify-aadhar-otp → verify-mobile.
• Then: check check-hpr-exist — if an HPR ID exists, done. Else suggest-ids → create-hpr.
• Returning professional (mobile login): get-mobile-otp → verify-mobile-otp → check-hpr-available.

HFR (facilities)

Always search-facility FIRST. Exists → link-facility. Not found → onboard-facility → link. (Facility registration itself may require the ABDM portal with document upload and NHA approval — programmatic APIs cover search/onboard/link; set expectations with the user that HFR approval is asynchronous and human-reviewed by NHA.)

Software linkage & Eka onboarding (the step people miss)

1. HPR ID created ✔ 2. Facility has HFR ID ✔
2. On the ABDM portal facility dashboard → Software Linkage → enter the Eka Bridge ID (OHPL_001 for Eka-managed credentials; BYOA clients use their own credential/bridge id). This is a manual portal step — instruct the user precisely.
3. POST /abdm/v1/hip/onboard (nhpr-abdm/onboarding.md) to register the facility in Eka's system. Only after this can the facility link care contexts (M2).

Integration blueprint

1. Admin screen in the client's HIS: "Register doctor" (HPR wizard) and "Onboard facility" (HFR search → link → onboard) flows. Or use the NHPR Web SDK: /SDKs/web-sdk/nhpr-sdk/get-started.md. Ask which the client wants for M4 specifically — the console's integration_method is stored per facility, not per milestone, so a client that used raw APIs or a different SDK for an earlier milestone may still want the NHPR SDK here (or vice versa). Don't assume continuity from a prior milestone; ask fresh.
2. Persist {hpr_id, doctor_id} and {hfr_id, facility_id, link_status} against the client's own entities; ask which tables. If using the NHPR Web SDK: pass the console-issued clientId at mount, and capture {hpr_id, hip_id, bridge_id} from the SDK's unmount callback — the SDK does not return the created clinic id any other way. hip_id is required later for M2 linking and Scan & Share.
3. Gate M2 linking on facility.onboarded == true to avoid confusing ABDM-1035 (Invalid HIP ID) errors later.

Fetch each endpoint's .md before coding (paths: ../abdm-overview/references/docs-map.md).

Test before done

HPR exists-path and create-path, HFR search hit/miss, onboard API success, and an M2 link attempt from a freshly onboarded facility.