India (`in`) — a filled-out country pack
Status: a starting point, not a finished pack. This is one contributor's attempt to fill in the template for India using only what could reasonably be sourced from public, primary-source material (official government notifications, national implementation guides, public classification pages) plus this project's own prior internal review — without a lawyer, an Indian health-IT specialist, or direct contact with the National Resource Centre for EHR Standards (NRCeS), the National Health Authority (NHA), or the Data Protection Board. Every answer below is tagged for how confident it is — do not treat an [L] tag as equivalent to a verified fact, the same convention the Philippines and Mexico examples already use.
A structural correction before the fields, not after: both existing worked examples (Philippines, Mexico) number their sections 1, 2, 3, 4, 5–6, 7, 8, 9, 10, 11, 12–13, 14, 15, 16, which skips field 13 (secondary_use_allowed) entirely and mislabels the combined-residency section (actually fields 12 and 16) as "12–13." This was checked directly against both source files rather than assumed. secondary_use_allowed is not a cosmetic omission to repeat: it is one of the two slots (with privacy_regime) that is actually read by running code — unlike coding_system/fhir_profile, which are wired to nothing. Leaving it unaddressed in a worked example is a bigger miss than leaving an inert field unaddressed. This example numbers sections by the interface's actual field order (1 through 17, with 5–6 combined as the two placeholder fields the template itself groups) and includes field 13 explicitly. India, Jamaica, and China's examples all follow this corrected numbering.
Confidence tags used below (same convention as the Philippines/Mexico examples):
- [L] — lay/general domain knowledge, or a fact read from a secondary source (a law firm's or a trade press's summary of a primary instrument) rather than the primary instrument's own text. Plausible and, where possible, sourced by name and URL below, but not independently verified against the primary legal or technical text.
- [SAFE] — a structural or internationally-standardized fact (an ISO code, a public registry entry) rather than a country-specific regulatory judgment call.
- NEEDS LOCAL INPUT — genuinely unknown, or known only through a secondary source not treated as authoritative for an operative regulatory fact. The question is the deliverable.
"in" — [SAFE], ISO 3166-1 alpha-2 for India.
system_id(): not yet named — depends on the answers below.- Diagnosis coding — [L], NEEDS LOCAL INPUT for the operative detail. India is a WHO member state; no confirmation, primary or secondary, was found that India's public health-reporting or insurance-claims systems have moved off ICD-10 onto ICD-11 for operative (as opposed to pilot) use. A search for evidence of national ICD-11 adoption surfaced only a single academic feasibility study of an ICD-11 pilot in West China — a different country, and a pilot, not a national rollout, named here explicitly so it is not mistaken for "India has adopted ICD-11." The precise question: does India's health ministry (MoHFW) or the Ayushman Bharat Digital Mission (ABDM, see Field 4) require a specific ICD-10 edition, or has any ICD-11 transition begun for claims (as opposed to statistical reporting)?
- Procedure and lab coding — NEEDS LOCAL INPUT, no confident answer for either. No source was found identifying which procedure code set (an ICD-9-CM-derived list, a payer-specific schedule, something else) an Indian claim or discharge summary actually carries. LOINC is a reasonable default to propose for lab coding — it is already the
us/pack's own choice and is Regenstrief's international standard, not a US-only vocabulary — but proposing it is not the same as confirming an Indian system expects it. - SNOMED CT is a genuinely confident, sourced answer — the strongest coding-system finding in any of the countries in this batch. India's Ministry of Health and Family Welfare has made SNOMED CT free for all use within India: India is a member of SNOMED International through the National Resource Centre for EHR Standards (NRCeS), which represents India at SNOMED International and issues a national affiliate licence free of any upfront or recurring fee for personal, research, educational, or commercial use within India — [L], sourced to SNOMED International's own member page and to NRCeS's own licensing explainer, not independently re-derived. NEEDS LOCAL INPUT: whether a specific SNOMED CT edition (India has worked on a national extension, per general NRCeS documentation) is operative for a given clinical category, and whether the free licence covers the specific commercial packaging this software would ship under.
regime_id():"IN-DPDP-2023"— [L], and this is a field where currency (not just correctness) matters more than in either the Philippines or Mexico example, because the law's implementing rules were still being finalized as recently as last year. The Digital Personal Data Protection Act, 2023 was passed in 2023; its implementing Digital Personal Data Protection Rules, 2025 were notified by the Ministry of Electronics and Information Technology (MeitY) on 13 November 2025, per MeitY's own press release. The Act is not uniformly in force even today (2026-09-12): per that same notification, the Rules take effect in phases — Rules 1, 2 and 17–21 from 13 November 2025; Rule 4 from 13 November 2026; and the bulk of the substantive rules (3, 5–16, 22–23) not until 13 May 2027. A Data Protection Board was simultaneously established. This is a live-currency risk named explicitly, the way the Mexico example named a stale NOM-024 citation risk: any statement of "what the DPDP Act requires" must specify which phase is operative on the date it is read, and the honest answer as of this document's date is that most of the Act's substantive machinery is not yet binding.consent_text(scope): NEEDS LOCAL INPUT — deliberately not drafted, per the template's own rule, and for a reason specific to India that neither the Philippines nor Mexico example encountered: health data flowing through the Ayushman Bharat Digital Mission (ABDM) is not consented to once, at the institution, the way a single privacy-regimeconsent_text(scope)call implies. ABDM's own Health Information Exchange & Consent Manager (HIE-CM) architecture — described in ABDM's own published specification — routes a patient's consent for a given data exchange through a Consent Manager: a separate, licensed entity the patient selects, which mediates each exchange between a Health Information Provider (HIP) and a Health Information User (HIU) as a discrete, per-transaction artifact, not a standing institutional policy. Whatever the DPDP Act's own general consent text should say (itself needing local input for a lawyer), it is a different, additional question from what an ABDM-integrated deployment's consent flow must present, and the two are not conflated here. See "Limits of the interface" below — this is the single largest structural finding of this example.retention_default_days(resource_type): NEEDS LOCAL INPUT for every resource type (Patient, Encounter, DiagnosticReport, Observation, MedicationRequest — the same five named in both prior examples' own framing). No confident figure held for Indian medical-record retention.export_rule(purpose): NEEDS LOCAL INPUT, and this is being kept unusually careful about not overclaiming. An uncertain, unverified impression is that the DPDP Act 2023 takes a "transfer permitted except to jurisdictions the government restricts" approach rather than a China-style default-localization approach (see the China example, this same set, for the opposite case) — but the Act's cross-border-transfer provision has not been read directly, only an impression formed from secondary summaries of the 2025 Rules, and no specific section number is cited here without verification. The precise question: what does the DPDP Act 2023 and its 2025 Rules actually require before health data leaves an Indian institution or India itself, and has any country-specific restriction list been notified under it?
A genuinely different answer from both prior examples: a real, dated, versioned national profile exists. Neither the Philippines nor Mexico example could point to a published national FHIR implementation guide; India's does exist. The National Resource Centre for EHR Standards (NRCeS) — set up by MoHFW at C-DAC Pune — publishes the FHIR Implementation Guide for ABDM, based on FHIR R4 (this project's own fixed baseline), currently at version 6.5.0, published at nrces.in/ndhm/fhir/r4 — [L], read from NRCeS's own site listing multiple dated versions (5.0.0, 6.0.0, 6.5.0), not independently verified resource-by-resource against the guide's own structure definitions. NEEDS LOCAL INPUT: (a) whether v6.5.0 is the version an ABDM-integrated deployment is actually expected to conform to today, given how frequently the version number has moved; (b) the specific profile URL value this pack would need per FHIR resource type — that requires a developer to read the guide itself. This is still not a claim that India's FHIR situation is "solved" for this pack — the open question changed shape, from "does a profile exist" (no, for Philippines and Mexico) to "which dated version of an existing profile, and does this deployment's own resource set match its scope" (India-specific, and still open).
"in-dpdp-v1" / "in-criteria-v1" — [SAFE] as placeholder names only, following the template's own guidance that no compliance-rule engine or policy-pack loader exists in this codebase for any country yet. Not a claim that either string means anything operationally today.
[L], with a NEEDS LOCAL INPUT on shape, closer to Mexico's fragmented case than the Philippines' single-payer one. India's public health-financing landscape includes at least: Ayushman Bharat PM-JAY (the national health-insurance scheme for economically vulnerable households), the Central Government Health Scheme (CGHS) (central-government employees and pensioners), the Employees' State Insurance (ESI) scheme (organized-sector workers), various state-government schemes (India's states run their own supplementary or parallel programs, a federal-structure wrinkle neither the Philippines' nor Mexico's examples needed to name), plus private commercial insurance and self-pay. A starting, deliberately hedged vocabulary: ("PM-JAY", "CGHS", "ESI", "state-scheme", "private", "self-pay"). NEEDS LOCAL INPUT: (a) should individual state schemes be named specifically or left as a category, given that which scheme applies can depend on the patient's state of residence, not just their institution; (b) does ABDM's own claims-exchange standard (NHCX, the National Health Claims Exchange, mentioned in NRCeS/ABDM materials but not independently verified here) define its own payer-type vocabulary this pack should mirror.
"INR" — [SAFE], ISO 4217 code for the Indian rupee.
NEEDS LOCAL INPUT on the default, and this is a harder open question than either prior example's locale field — a genuine product decision with more at stake than the Philippines' English-vs-Filipino question. An internal review states English is used "nationwide for documentation and IT" in India, which would make en-IN a workable default for clinical charting and system UI, matching the Philippines' logic. But the same review immediately adds a qualifier neither the Philippines nor Mexico case needed: patient-facing text in a regional language matters — Hindi alone does not serve the south. India recognizes 22 languages in the Eighth Schedule of its Constitution, and clinical documentation practice varies by state in a way no single BCP-47 tag can resolve. A starting, explicitly incomplete answer: en-IN for the interface default, with NEEDS LOCAL INPUT, not a placeholder detail but the actual open question: which regional language(s) must the consent-text function be prepared to render in for a deployment outside a Hindi- or English-dominant state, and does that requirement vary institution-by-institution the way Mexico's privacy regime varies by public/private ownership?
NEEDS LOCAL INPUT — not assumed, per the template's own instruction that this field is patient-safety-adjacent and must not be inferred from everyday convention. No specific format is guessed here pending confirmation against an actual national insurance claim form or MoHFW reporting form, the same discipline both prior examples applied to this field.
NEEDS LOCAL INPUT, and the shape of the open question here is genuinely new, not just an unconfirmed instance of the binary the template describes. The template's Field 11 frames the choice as 1,234.56 versus 1.234,56 — comma-thousands/period-decimal or the reverse. India's everyday numbering convention (the "lakh/crore" system) groups digits differently from both: after the first three digits from the decimal point, subsequent groups are of two digits rather than three (for example, one million as 10,00,000 rather than 1,000,000) — [L], commonly known, not independently verified against an official lab or prescription template. NEEDS LOCAL INPUT: does an Indian lab report or prescription actually use this grouping, or does it follow the international 1,000,000-style grouping instead (both are used in different contexts in India, per an uncertain understanding)? This is flagged in "Limits of the interface" below as a finding about the template itself, not only about India: the template's own binary framing for this field does not anticipate a third digit-grouping convention.
NEEDS LOCAL INPUT. No confirmation was found of a health-data-specific residency mandate under the DPDP Act 2023 comparable to China's (see the China example) — India's general data-protection framework is understood, at a lay level, to take a lighter cross-border-transfer approach than PIPL/DSL (Field 3 above) — but sector-specific rules exist elsewhere in Indian law (the Reserve Bank of India's payment-data localization mandate is the most commonly cited example, not itself a health-sector rule and cited here only to show that sector-specific residency rules are a known pattern in India, not to imply health data is covered by it). The precise question: does any ABDM policy document, MoHFW circular, or the DPDP Rules' health-sector provisions (once the relevant Rules take effect — see Field 3's phasing caveat) impose a residency condition on health data specifically?
NEEDS LOCAL INPUT, and this field deserves more attention than either prior worked example gave it (see the numbering correction at the top of this document) precisely because it is one of the two container slots this codebase's capture module actually reads at runtime — a wrong answer here does not sit inert the way a wrong coding_system answer currently does. No confident answer is held for whether Indian law permits, by default, health data collected for direct care to be reused for research or population-health analytics without a fresh, purpose-specific authorization. The safe interim answer, matching the xx stub's own convention exactly as the interface's own comment describes, is false until a lawyer confirms otherwise — the failure mode of guessing true here is not hypothetical prose, it is a real code path this project has already wired.
NEEDS LOCAL INPUT, with a lean toward None. No Indian enumerated, HIPAA-Safe-Harbor-style de-identification standard published by MeitY, the Data Protection Board, or MoHFW is known. If an Indian health-IT or legal contributor confirms none exists, the honest value is None — matching the convention both prior examples and the xx stub itself already establish.
NEEDS LOCAL INPUT, with a lean toward None for the same reason as Field 14: no published Indian national-statistics or health-ministry small-cell suppression rule for health data is known, and its absence has not been confirmed with anything more than an unconfirmed search.
NEEDS LOCAL INPUT — the boolean counterpart to Field 12, kept consistent with it per the specification's own consistency requirement. Same open question, same source.
[L], moderate-to-low confidence. India's biomedical and health research is generally understood to require review by an Institutional Ethics Committee, commonly registered with or operating per guidance from the Indian Council of Medical Research (ICMR), and separately, clinical-trial-specific ethics committees are registered with CDSCO (the same body named below in the Software-as-Medical-Device discussion) for trials specifically, not necessarily for the kind of secondary-use scenarios this field is meant to gate. A starting, hedged value: ("Institutional Ethics Committee (ICMR-guided)",). NEEDS LOCAL INPUT: whether a single national accrediting body plays the role PHREB plays for the Philippines, whether the Data Protection Board established under the DPDP Act (Field 3) will have any separate approval role for health-data secondary use once its substantive rules take effect (May 2027 per the phasing above), and whether ABDM's own Health Information Exchange has an approval-gate concept distinct from either.
Neither the Philippines nor Mexico example needed to raise this, because no equivalent classification regime was found cited for either country with the same specificity available for India. India's drug-and-device regulator, the Central Drugs Standard Control Organisation (CDSCO), brought standalone software performing a medical purpose ("Software as a Medical Device," SaMD) within the Medical Device Rules, 2017 via Notification S.O. 648(E), dated 11 February 2020 — [L], read from secondary legal-analysis sources describing the notification and CDSCO's subsequent risk-based classification (Class A through D, low to high risk), not independently verified against CDSCO's own gazette text. This project's own decision-support code already exists — drug-interaction checking, critical-value alerting — which is exactly the category of feature that tends to draw device-classification scrutiny under CDSCO's risk tiers. The country pack container has no field for "does this deployment's feature shape, if it includes decision support, become a regulated medical device in this jurisdiction" — not a gap in this example's research, a gap in the interface itself — named here because it is directly actionable: whether a given India deployment may ship decision-support features at all is gated by an answer this container has no field to carry. See "Limits of the interface" below.
Summary: what this worked example proves and what it does not
Proves: the template holds up on a third country with a genuinely different shape from either prior example — federated, multi-language, multi-payer, multi-state — and, unlike both priors, found one field (fhir_profile) with a real, dated, citable national implementation rather than an absence to report. It also found a live-wired field (secondary_use_allowed) that both prior examples skipped, and treats that field with the seriousness its actual runtime effect deserves rather than the passing treatment an inert field would get.
Does not prove: that India is closer to shippable than the Philippines or Mexico. Of 17 fields, a rough count: 3 are reasonably safe today (pack_id, currency, the two placeholder identifiers), 2 have a confident-enough answer to build on (SNOMED CT's free national licensing; the existence, though not the exact operative version, of a national FHIR implementation guide), 1 is a genuine, still-open product decision rather than a missing fact (locale's regional-language question, which is harder than the Philippines' equivalent question because it is multi-way, not binary) — and every other field remains open, including the single field (secondary_use_allowed) whose wrong answer today would actually change running behavior, which neither the Philippines nor Mexico example flagged with this weight.
Three findings this example surfaces that the Philippines and Mexico examples, being differently shaped cases, had no occasion to produce:
- India's consent architecture is not "one law, one text" (Philippines) or even "two regimes, chosen at install time" (Mexico) — it is a live, per-transaction protocol exchange mediated by a patient-selected third party (ABDM's Consent Manager), and the consent-text function has no way to represent that at all. Mexico's own "Limits of the interface" finding was that the container assumes one privacy regime per pack, when a country may need two, selected once at install time by institution type. India's finding is a different kind of gap: even a single, correctly-selected privacy-regime implementation can only return a static string for a given scope, but ABDM's actual consent mechanism is not a string a system displays once — it is a dynamic, auditable, per-exchange handshake with an external registered entity the patient chooses. This is not fixable by writing better prose into the consent-text function; it is a different mechanism the container's three slots do not name at all, and — unlike Mexico's finding, which the specification already addresses with a two-packs workaround — no equivalent workaround is visible under the current specification, only a note that a future version should look at it.
- India has more than two working languages relevant to a single pack, and the template's
localefield forces a single BCP-47 tag. The Philippines' locale question was binary (English or Filipino as the default). Mexico's was a non-question (Spanish, full stop). India's is neither: English serves documentation and IT nationally, but patient-facing consent text plausibly needs one of several regional languages depending on the state, and no single tag captures "the right answer depends on where in the country this is installed." This is the same shape of problem Field 3 raises for privacy regime (a per-institution or per-region seam the container does not have), surfacing a second time on a different field. - The interface has no field at all for device-classification exposure (the CDSCO Software-as-Medical-Device finding above). This is a different kind of limit from the first two: it is not that one field's shape is too narrow, but that a real, jurisdiction-varying, gating legal fact — whether shipping a given feature set turns the software into a regulated medical device — has no field to live in at all, anywhere in the 17. A pack author following this template today has nowhere to record "decision support is Class C in this jurisdiction," and a consumer has nothing to read even if a pack author invented somewhere to put it.