On this page · 11 sections
- What ChatGPT Health actually does, and why it stops at the US border
- The India-ready version: same job, different rails
- Why you cannot just ship ChatGPT Health in India: the DPDP Act 2023
- ABDM: the rails your assistant has to run on
- A reference architecture for a compliant health-records assistant
- The clinical line: when your assistant becomes a medical device
- India-specific considerations
- A phased build plan
- FAQ
- How eCorpIT can help
- References
Summary. OpenAI launched Health in ChatGPT on 23 July 2026 for logged-in US users aged 18 and over, letting them connect Apple Health and supported medical records so the assistant can read lab trends, medications and visit notes in context. India is not on the list. That gap sits on top of a market that Grand View Research valued at USD 14.50 billion in 2024 and projects at USD 106.97 billion by 2033, a 25.12% compound annual rate. India already has the data rails: the Ayushman Bharat Digital Mission (ABDM) has issued 93.95 crore ABHA numbers and linked more than 105 crore health records as of July 2026. Any team that wants to serve that demand has to build for two hard constraints ChatGPT Health does not face here: the Digital Personal Data Protection (DPDP) Act 2023, whose penalties reach ₹250 crore per violation and whose core provisions bite from 13 May 2027, and ABDM's consent-driven Health Information Exchange. This guide sets out what to build.
What ChatGPT Health actually does, and why it stops at the US border
Health in ChatGPT is a context layer, not a diagnosis engine. With permission, it draws on information a user connects, such as medications, lab results, recent visits, sleep and activity, and uses that to compare a new result against prior tests or summarise what changed since the last appointment. OpenAI reports that more than 300 million people each week already ask ChatGPT health questions, and the feature is meant to stop them re-uploading the same records every time. On the free plan it runs on GPT-5.5 Instant; paid users get GPT-5.6 Sol, which OpenAI calls its strongest health model.
The privacy posture is specific. OpenAI states that connected medical records and Apple Health information, "and conversations that use it, are not used to train our foundation models or target ads." Access is permission-gated by default, and when a user disconnects a source, OpenAI says the synced data is deleted from its systems within 30 days.
The launch is confined to the United States, on web and iOS, across the Free, Go, Plus and Pro tiers. The supported connectors are US-shaped: Apple Health, US hospital-system records, One Medical and Function Health. None of that maps onto Indian primary care, where the record layer is ABDM, the identity is the ABHA number, and the legal frame is the DPDP Act rather than HIPAA. A team cannot port the US product; it has to build the India-native equivalent. The rest of this guide is that build.
The India-ready version: same job, different rails
The useful mental model is to keep ChatGPT Health's job and replace every rail underneath it. The assistant still turns scattered records into a plain-language timeline; it just sources those records from ABDM under Indian consent law and keeps the data inside an Indian compliance boundary.
| Layer | ChatGPT Health (US, July 2026) | India-ready assistant you build |
|---|---|---|
| Identity | Apple Health account, US patient portals | ABHA number issued under ABDM |
| Record source | US hospital systems, One Medical, Function Health | ABDM HIE-CM, federated provider records |
| Data standard | Proprietary connectors plus Apple Health | HL7 FHIR R4, ICD-10, SNOMED CT, LOINC |
| Consent | App-level permission prompt | Time-bound, revocable ABDM consent artefact |
| Governing law | HIPAA and state rules | DPDP Act 2023 and DPDP Rules 2025 |
| Model hosting | OpenAI cloud (US) | In-region model endpoint or private deployment |
Every row on the right is a design decision with legal weight, so it pays to take them in order: the law first, then the data rails, then the model.
Why you cannot just ship ChatGPT Health in India: the DPDP Act 2023
The DPDP Act received assent in August 2023, and the DPDP Rules were notified on 13 November 2025. The consent, notice and security obligations become enforceable from 13 May 2027, which is the deadline every health-app roadmap should be planning against now. Penalties reach up to ₹250 crore per violation for a failure to take reasonable security safeguards.
One point trips up teams porting a Western design. The DPDP Act does not create a separate, higher tier for sensitive personal data the way the GDPR does, and it defines no special health-data category, as a digital-health reading of the DPDP Act sets out. That does not make health data easier to handle; it means the general obligations apply in full, and a health-records assistant is very likely to be designated a Significant Data Fiduciary (SDF) once the government weighs the volume and sensitivity of what it processes.
| DPDP obligation | What the rule requires | How it shapes the build |
|---|---|---|
| Consent and notice | Clear, itemised, withdrawable consent before processing | A consent ledger, per-purpose scoping, one-tap withdrawal |
| Significant Data Fiduciary status | India-based Data Protection Officer, independent auditor, DPIA | Named DPO, audit logging from day one, a documented DPIA |
| Children's data (Rule 10) | Verifiable parental consent for under-18s; no behavioural tracking or targeted ads | Age gate, DigiLocker-based parent verification, no ad tech |
| Security safeguards | Reasonable measures; breach reporting | Encryption at rest and in transit, access controls, breach runbook |
| Consent Manager framework | Interoperable consent, being operationalised through 2026 | Design to plug into a registered Consent Manager, not a private silo |
The children's-data rule deserves a flag. DPDP Rule 10 requires verifiable parental consent before processing a minor's data, with approved methods including DigiLocker to confirm the parent's identity and the parent-child link, and it bars tracking, behavioural monitoring and targeted advertising aimed at children. A paediatric or family health assistant has to gate this before it reads a single record.
ABDM: the rails your assistant has to run on
ABDM is run by the National Health Authority (NHA). It is not a database you query; it is a federated exchange. As the NHA's own material puts it, health records "are stored with healthcare information providers" and "shared over the ABDM network with encryption mechanisms only after your express consent." There is no central pile of records to tap, which is a deliberate design choice and a compliance advantage.
Three gateways matter. HIE-CM, the Health Information Exchange and Consent Manager, brokers consent-based clinical record sharing. NHCX handles insurance claims. UHI handles service discovery. For a records assistant, HIE-CM is the one that counts: it issues the time-bound, revocable consent artefact that lets your app pull a patient's records from the facility that holds them.
The data itself is standardised. ABDM mandates HL7 FHIR R4, with ICD-10, SNOMED CT and LOINC for clinical coding, published through the NRCeS FHIR Implementation Guide maintained by the National Resource Centre for EHR Standards under C-DAC. In practice, your assistant will parse FHIR bundles, resources such as Patient, Observation, MedicationRequest and Condition, rather than the proprietary shapes ChatGPT Health reads from Apple Health. Getting the FHIR parsing and terminology mapping right is most of the integration work, and it is the same work an ABDM-compliant hospital system faces. Teams that have already handled CDSCO and DPDP data architecture for clinical systems will recognise the shape of it.
A reference architecture for a compliant health-records assistant
Put the pieces together and a defensible architecture falls out. The design principle is that consent and residency are load-bearing, not features bolted on at the end.
The flow starts with ABHA-based identity: the user authenticates with their ABHA number, and your app never becomes the identity provider. A consent request goes through HIE-CM, scoped to a purpose and a time window; the returned artefact is stored in a consent ledger you can produce for an auditor. Records arrive as FHIR R4 bundles, which a normalisation service maps into a working clinical model. Only then does the language model see anything, and it sees the minimum: a de-identified or access-controlled slice, never the raw record dump.
Model hosting is the decision that most separates an Indian build from ChatGPT Health. Sending Indian patients' records to a US inference endpoint reopens every residency and DPDP question you just closed. The alternatives are an in-region hosted frontier model or a private deployment inside your own boundary.
| Model approach | Data control | Time to market | Ongoing cost profile | Best fit |
|---|---|---|---|---|
| US public API (ChatGPT Health style) | Weakest; cross-border transfer | Fastest | Low fixed, per-token | Not advisable for Indian health records |
| In-region hosted frontier model | Strong; data stays in India region | Fast | Per-token, higher than US list | Most product teams |
| Private or self-hosted open model | Strongest; full boundary control | Slowest | High fixed GPU cost, low marginal | SDF-scale or hospital deployments |
There is a plain engineering judgement worth stating here. The hard part is rarely the model; it is the consent plumbing, the FHIR normalisation and the audit trail. Those decide whether you pass a DPDP audit, and they are where most of the schedule goes. Teams that under-scope them ship a demo that cannot go live. The DPDP Act engineering playbook covers the consent-ledger and data-mapping patterns in more depth.
The clinical line: when your assistant becomes a medical device
ChatGPT Health is careful to position itself as "supporting, not replacing" professional care. That framing is not just bedside manner; it is where the regulatory line sits. An assistant that organises records, explains a lab value in plain language and helps a patient prepare questions is an information tool. One that interprets an image, flags a diagnosis or recommends a treatment change is edging into Software as a Medical Device (SaMD).
In India, SaMD falls under the Central Drugs Standard Control Organization (CDSCO), which in October 2025 released draft guidance on Medical Device Software under the Medical Device Rules, 2017. SaMD is risk-classified from Class A to Class D, and the draft guidance introduced an Algorithm Change Protocol, a pre-agreed protocol that lets a model be updated iteratively without a fresh licence for every change, which matters for any system that retrains. There is a separate line for clinical practice: under the Telemedicine Practice Guidelines, only practitioners registered with the National Medical Commission or a State Medical Council may practise telemedicine, so an assistant must not present itself as the prescriber. Decide early which side of the SaMD line your product sits on, because it changes your regulatory path entirely. The common healthcare AI deployment mistakes in Indian hospitals almost all trace back to getting this classification wrong late.
India-specific considerations
Data residency is the first. ABDM's federated model already keeps records with the provider that created them, and the National Health Authority's Health Data Management Policy sets the data-handling rules for everyone on the network, so a design that ships records to a foreign region works against the grain of the whole system. Keep processing and model inference inside an Indian region.
Language is the second. India's records and patients are multilingual, and a US model tuned on English-language portals will under-serve Hindi, Bengali, Tamil and the rest. Plan for Indian-language handling as a first-class requirement, not a later add-on.
Trust is the third. With 93.95 crore ABHA numbers issued and Uttar Pradesh alone past 15.3 crore, the audience is national and largely first-time digital-health users. Consent has to be legible in plain language, and the app has to make withdrawal as easy as granting. That is both a DPDP requirement and the difference between adoption and abandonment.
A phased build plan
A workable sequence is to prove the compliance spine before the clever parts. Phase one is ABHA authentication, an HIE-CM consent flow and a consent ledger, with FHIR ingestion for two or three common record types. Phase two adds the normalisation layer and an in-region model that summarises records and answers questions on connected data only. Phase three widens record coverage, adds Indian-language support and hardens the SDF obligations: a named India-based DPO, independent audit, and a documented Data Protection Impact Assessment. Only after that spine holds should the roadmap chase the conversational polish that makes ChatGPT Health feel effortless. For a broader view of the clinical stack, the clinical AI deployment in India guide sets the wider context.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based, ISO 27001:2022-certified engineering organisation that builds ABDM-integrated products and designs applications aligned with DPDP Act 2023 requirements. Our senior teams handle the parts that decide a health-records assistant's fate: ABHA authentication, HIE-CM consent flows, FHIR R4 normalisation and in-region model deployment with a full audit trail. If you are planning an India-native answer to ChatGPT Health, our healthcare app development team can scope the compliance spine before the product. Start a conversation at /contact-us/.
References
_Last updated 28 July 2026._
