Ndhm Health Repository Provider Specifications for HIU

Name: Health Repository Provider Specifications for HIU API
Brand: Health Repository Provider Specifications for HIU
Availability: InStock

Browse all Ndhm APIs

★ Only Publicly Available OpenAPI DocumentHealthcareEhr Emrnone32 Endpoints

Install Jentic One Beta

Connect the Health Repository Provider Specifications for HIU to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Health Repository Provider Specifications for HIU, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Health Repository Provider Specifications for HIU API.

Raise consent requests for patient records via /v0.5/consent-requests/init

Handle consent state callbacks at /v0.5/consents/hiu/on-notify

Fetch granted consent artefacts using /v0.5/consents/fetch and on-fetch

GET STARTED

Start building with Health Repository Provider Specifications for HIU API

Explore with Jentic

View OpenAPI Document

For Agents

Implement and call the Health Information User side of NDHM - raise consent requests, receive consent state callbacks, request and receive encrypted health records.

Use for: I need to raise a consent request for patient lab reports, Fetch a consent artefact granted by the patient, Request encrypted records from the patient's HIP, Receive a transferred FHIR bundle on the HIU side

Not supported: Does not issue consent artefacts, store records, or manage ABHA identifiers - use for the NDHM HIU record-requesting role only.

Jentic publishes the only available OpenAPI specification for Health Repository Provider Specifications for HIU, keeping it validated and agent-ready. This specification covers the endpoints a Health Information User must implement and call to participate in India's NDHM network - typically an insurer, doctor, telehealth platform, or research entity that needs consented access to patient records. The 32 endpoints cover identification, consent flow callbacks, health information requests and on-request callbacks, encrypted record receipt via /v0.5/health-information/transfer, and Gateway-facing helpers such as certs and OpenID configuration.

Use Cases

Patterns agents use Health Repository Provider Specifications for HIU API for, with concrete tasks.

★ Insurer Claims HIU Workflow

An insurer acting as an HIU raises a scoped consent request for the encounters covered by a claim, fetches the artefact when granted, and requests the encrypted FHIR bundle from the relevant HIP. The HIU receives the records via /v0.5/health-information/transfer, decrypts them locally, and reconciles them against the claim. The flow is async and bounded by the consent's validity window.

POST /v0.5/consent-requests/init with the encounter scope, then on grant call /v0.5/consents/fetch and /v0.5/health-information/cm/request to retrieve the encrypted bundle.

Telemedicine Pre-Consultation Record Pull

A telemedicine platform acting as an HIU pulls the patient's recent labs and prescriptions before a consultation. The HIU raises a short-validity consent request, the patient approves it on their CM, and the telemedicine app receives the encrypted FHIR bundle on /v0.5/health-information/transfer in time for the doctor to review. Integration follows the NDHM 0.5 callback choreography.

POST /v0.5/consent-requests/init with a 1-hour validity window covering the requested HI types, then receive the encrypted bundle on /v0.5/health-information/transfer.

Research Cohort Data Access

A research entity registered as an HIU raises consent requests against a cohort of opted-in citizens, fetches the granted artefacts, and pulls de-identified records from each citizen's HIP. The HIU enforces the artefact's purpose and validity locally, since NDHM does not police these constraints downstream. This pattern is common for public-health and clinical-trial use cases.

Iterate over a cohort of ABHA ids and POST /v0.5/consent-requests/init for each, scoped to the research purpose and the agreed HI types.

Agent-Driven HIU Operations

An AI agent embedded in an HIU back-office uses Jentic to orchestrate the consent-and-fetch loop without rebuilding signing, async callback, and decryption scaffolding for every project. The agent searches for the right operation, loads the schema, and submits the consent request and health information request while Jentic manages the participant credentials.

Search Jentic for 'request health information as HIU', load the schema for /v0.5/health-information/cm/request, and execute it with the consent id and HIP id.

Key Endpoints

32 endpoints — jentic publishes the only available openapi specification for health repository provider specifications for hiu, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

POST

/v0.5/consent-requests/init

Raise a consent request

POST

/v0.5/consent-requests/status

Check consent request status

POST

/v0.5/consents/fetch

Fetch a granted consent artefact

POST

/v0.5/consents/hiu/on-notify

Receive consent notification on HIU side

POST

/v0.5/health-information/cm/request

Request health information from CM

POST

/v0.5/health-information/hiu/on-request

HIU on-request callback for data flow

POST

/v0.5/health-information/transfer

Receive encrypted health information transfer

POST

/v0.5/consent-requests/init

Raise a consent request

POST

/v0.5/consent-requests/status

Check consent request status

POST

/v0.5/consents/fetch

Fetch a granted consent artefact

POST

/v0.5/consents/hiu/on-notify

Receive consent notification on HIU side

POST

/v0.5/health-information/cm/request

Request health information from CM

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Your HIU signing keys, id header, and gateway client secret are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.

Intent-based discovery

Agents search Jentic by intent such as 'request health information as an HIU' or 'check consent request status', and Jentic returns the matching HIU operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

Time to first call

FAQs

Specific to using Health Repository Provider Specifications for HIU API through Jentic.

Why is there no official OpenAPI spec for Health Repository Provider Specifications for HIU?

The National Health Authority publishes HIU responsibilities as written specifications and reference Postman collections rather than an OpenAPI document. Jentic generates and maintains this spec so that AI agents and developers can call Health Repository Provider Specifications for HIU via structured tooling. It is validated against the NDHM 0.5 specification and kept up to date. get started with Jentic One, the self-hosted execution layer.

What authentication does the NDHM HIU API use?

The OpenAPI spec does not declare a top-level security scheme because HIU endpoints validate Gateway-issued JWTs against the certificates published at /v0.5/certs and require the X-HIU-ID header. Through Jentic the HIU signing keys and id are stored encrypted in the vault and applied at execution time, so the agent context never sees the long-lived secret.

Can I receive encrypted health records with the HIU API?

Yes. After raising a consent request and receiving the granted artefact, POST /v0.5/health-information/cm/request to ask for the records. The HIP transfers the encrypted FHIR bundle to your /v0.5/health-information/transfer endpoint, where the HIU decrypts and processes it.

What are the rate limits for the HIU API?

The NDHM 0.5 specification does not publish per-endpoint rate limits in the OpenAPI document; throughput is governed by the participant onboarding agreement with the National Health Authority. Treat the dev.ndhm.gov.in/gateway sandbox as low-throughput and back off on 429 or 503 responses.

How do I raise a consent request through Jentic?

Run pip install jentic, then search for 'raise patient consent request', load the schema for POST /v0.5/consent-requests/init, and execute it with the requesting HIU id, patient ABHA id, requested HI types, and validity window. Jentic returns the acknowledgement and the on-init callback payload.

Does the HIU API store the records it receives?

No. The HIU API only handles the consent and transfer choreography. Storage, decryption, and downstream processing of the FHIR bundle happen inside the HIU's own systems.

Ndhm Health Repository Provider Specifications for HIU

Connect the Health Repository Provider Specifications for HIU to your agent

Capabilities

Start building with Health Repository Provider Specifications for HIU API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs