Health Repository Provider Specifications for HIU

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

★ Only Publicly Available OpenAPI DocumentHealthcareEhr Emrnone32 EndpointsREST

For Agents

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.

Install Jentic One Beta (Self-Hosted)

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

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

Request health information from a HIP through /v0.5/health-information/cm/request

GET STARTED

Start building with Health Repository Provider Specifications for HIU API

Explore with Jentic

View OpenAPI Document

Jentic publishes the only available OpenAPI document for Health Repository Provider Specifications for HIU, keeping it validated and agent-ready.

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 though Jentic?

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

Credential isolation

HIU signing keys, X-HIU-ID, and Gateway client secrets are stored encrypted in the Jentic vault. Agents receive scoped tokens at execution time so raw signing material never enters agent context.

Intent-based discovery

Agents search by intent such as 'request health information as HIU' and Jentic returns the matching HIU operation with its input schema, removing the need to read the NDHM specifications.

Time to first call

Direct NDHM HIU integration: 3-6 weeks plus NHA certification. Through Jentic: under a day to call individual HIU operations with managed credentials, certification still required to operate as a participant.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Complementary

NDHM Gateway

Routes the consent and data requests an HIU initiates

Use when the agent must call other NDHM participants on behalf of the HIU.

Complementary

NDHM HIP Specifications

Record-holding counterpart that fulfils HIU data requests

Use when the agent represents the record-holding party rather than the requesting HIU.

Complementary

Health Data Consent Manager

Issues the consent artefacts the HIU presents to HIPs

Use when the agent must verify, fetch, or manage the consent artefact behind an HIU request.

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 at https://app.jentic.com/sign-up.

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.