Mexico (`mx`) — 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 Mexico using only what could reasonably be sourced without a lawyer, a Mexican health-IT specialist, or direct contact with CENETEC, the Secretaría de Salud, IMSS, ISSSTE, or INAI. It is written to be handed to exactly such a person so they can correct it, answer what is marked open, and tell us what was gotten wrong. Every answer below is tagged for how confident it is — do not treat an [L] tag as equivalent to a verified fact.
Why Mexico, and why it is the harder one: the Philippines example exists because English is the working language of Philippine healthcare documentation, which made it the lowest-risk country to start with. Mexico is the opposite case on purpose. Per an internal Advisor review of the five target countries, "Spanish first, and it is not close" — Mexico is the one country of the five that genuinely cannot run this product in English: clinicians there chart in Spanish, and both of Mexico's binding technical instruments are Spanish-language by construction (NOM-024-SSA3-2012, the electronic clinical record standard, and CIE-10, the Spanish-language edition of ICD-10). Building this second example in Spanish, rather than a second English-speaking country, is the actual test of whether the template and the internationalization scaffold hold up outside the easy case.
Confidence tags used below (same convention as the Philippines example):
- [L] — lay/general domain knowledge, including facts sourced from an internal Advisor review of this rollout (itself tagged [L] there). Plausible and internally cited, but not verified against a primary Mexican legal or technical source (no access to a Diario Oficial publication, a CENETEC implementation guide, an IMSS/ISSSTE/SSA claims specification, or INAI guidance was available while building this).
- [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 to this document. The question is the deliverable.
"mx" — [SAFE], ISO 3166-1 alpha-2 for Mexico.
system_id(): not yet named — depends on the answers below.- Diagnosis coding — [L], NEEDS LOCAL INPUT for the operative detail. Mexico codes in CIE-10 (Clasificación Internacional de Enfermedades, 10ª revisión) — the Spanish-language WHO edition, not the US clinical modification (ICD-10-CM). NEEDS LOCAL INPUT: which specific CIE-10 edition/update year does DGIS (Dirección General de Información en Salud) require for the mandatory federal statistical return, and — because Mexico has three separate major public payers rather than the Philippines' single PhilHealth (see Field 7) — do IMSS, ISSSTE, and the successor to SSA claims each cite the same CIE-10 edition, or does one lag?
- Procedure coding — NEEDS LOCAL INPUT, no confident answer. An uncertain recollection is that Mexico has historically paired CIE-10 (diagnosis) with a CIE-9-MC-style procedure classification, but that is not asserted as fact. The precise question: which procedure code set does a Mexican facility claim actually carry — a CIE-9-MC-derived list, a payer-specific catálogo (IMSS and ISSSTE each maintain their own internal service/procedure catalogues, per an uncertain understanding), or something NOM-024-specific?
- Lab coding — NEEDS LOCAL INPUT. Does NOM-024-SSA3-2012 or a CENETEC interoperability guide mandate LOINC, a national lab code list, or leave this unspecified? LOINC is a reasonable default to propose (it is already the
us/pack's own choice, and LOINC is an international vocabulary, not a US-only one), but proposing it is not the same as confirming Mexican systems expect it. - NOM-024-SSA3-2012 itself is the standing question, not just a citation. NOM-024-SSA3-2012 is understood to be "the electronic clinical record standard" — [L]. It was published in 2012, over a decade before this document. NEEDS LOCAL INPUT: has NOM-024 been revised, superseded, or supplemented since 2012 (Mexican NOMs are periodically updated or replaced), and does its current text specify any of the coding-system questions above directly, or does it govern the record's structure while leaving code-set selection to each payer? Treating a 2012 citation as still-current without checking is exactly the kind of stale-fact risk this template warns against.
regime_id(): NEEDS LOCAL INPUT on the mechanism itself, not just the value. A tentative placeholder,"MX-LFPDPPP-LGPDPPSO", names both laws rather than picking one, because which one actually governs depends on facts not yet available (see next item).- The privacy regime is not one law, and that is itself a finding this example surfaces that the Philippines one did not need to. Mexico runs two parallel data-protection statutes depending on who controls the data — LFPDPPP (Ley Federal de Protección de Datos Personales en Posesión de los Particulares; private-sector controllers, updated by a new law in 2025) and LGPDPPSO (Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados; public-sector/government controllers) — [L]. Most Mexican care is public (IMSS/ISSSTE/SSA). NEEDS LOCAL INPUT, and this is the single most consequential open question in this whole example: for a clinic or hospital that is part of IMSS, ISSSTE, or the SSA-run public system, is the public-sector law (LGPDPPSO) the one that actually governs patient data there, meaning a Mexico pack for a public-sector deployment needs a materially different privacy-regime implementation than one built for a private Mexican clinic under LFPDPPP? A pack that silently assumes the private-sector law applies everywhere could be wrong for the majority of Mexican care. This is a structural question, not a fill-in-the-blank one, and it needs a Mexican health-data lawyer before either regime's specific consent/retention/export answers are drafted.
consent_text(scope): NEEDS LOCAL INPUT — deliberately not drafted, for both possible regimes. Operative consent text is a question for a lawyer licensed in Mexico (and specifically one who can say which of LFPDPPP/LGPDPPSO applies to a given deployment) or the relevant regulator's own published model language, never a plausible paraphrase — health data is explicitly sensitive personal data ("datos personales sensibles") under Mexican law [L], but that alone does not authorize drafting actual text.retention_default_days(resource_type): NEEDS LOCAL INPUT for every resource type (Patient, Encounter, DiagnosticReport, Observation, MedicationRequest). No confident figure held for Mexican medical-record retention under either statute. The precise question: what retention period does the applicable federal or state health regulation — medical-record retention in Mexico may also be addressed by the Ley General de Salud or NOM-004-SSA3-2012, the clinical-record-content NOM, separately from NOM-024 (unconfirmed) — set for each resource type, and does it differ between IMSS/ISSSTE facilities and private ones?export_rule(purpose): NEEDS LOCAL INPUT. Unlike the Philippines example, which had a lay-level "accountability principle" to point to, there is not enough confidence in any general principle about LFPDPPP/LGPDPPSO cross-border transfer rules to state even a hedged claim here. The honest state is this is unknown, and the question is: what does either statute require before health data leaves the controlling institution, or leaves Mexico, for a secondary purpose?
NEEDS LOCAL INPUT, entirely. No evidence was found, and no assumption is made, that CENETEC (Centro Nacional de Excelencia Tecnológica en Salud, Mexico's health-technology standards authority — [L], not independently verified) or the Secretaría de Salud publishes a national "MX Core" FHIR R4 implementation guide analogous to US Core. The precise question: does CENETEC or DGIS publish a FHIR implementation guide today? If not — the more likely answer absent evidence otherwise — what does a system actually need to satisfy NOM-024-SSA3-2012's own data-exchange requirements, since NOM-024 (a national record-content and interoperability standard predating FHIR's own widespread adoption) may be the real, binding technical constraint rather than any FHIR profile?
"mx-lfpdppp-v1" / "mx-criteria-v1" — [SAFE] as placeholder names only. No compliance-rule engine or policy-pack loader exists in this codebase for any country yet. The lfpdppp half of the first name is itself provisional pending the Field 3 question above about which statute actually governs — a public-sector deployment might reasonably want "mx-lgpdppso-v1" instead once that is resolved. Not a claim that either string means anything operationally today.
[L], with a larger NEEDS LOCAL INPUT on shape than the Philippines needed. Unlike the Philippines' single dominant national payer (PhilHealth), Mexico's public system is fragmented across multiple major institutions: IMSS (Instituto Mexicano del Seguro Social — formal private-sector employees), ISSSTE (Instituto de Seguridad y Servicios Sociales de los Trabajadores del Estado — public-sector/government employees), and a third tier for the previously-uninsured population. An uncertain understanding is that INSABI (Instituto de Salud para el Bienestar) was dissolved around 2023 and its functions absorbed into IMSS-Bienestar, but a health-system reorganization of that scale is not asserted without a current, dated source — it is not known which name is correct as of this document's date. A starting, deliberately hedged vocabulary: ("IMSS", "ISSSTE", "IMSS-Bienestar", "private", "self-pay"). NEEDS LOCAL INPUT, three questions: (a) what is the current, correctly-named public-sector payer/programme structure for the previously-uninsured population; (b) do the armed forces and Pemex operate their own separate health systems that a claims-facing deployment would need as distinct categories (Sedena/Marina and Pemex have historically run parallel systems outside IMSS/ISSSTE, but this is not asserted as settled); and (c) should specific named private insurers be enumerated individually, or is a category-level "private" sufficient?
"MXN" — [SAFE], ISO 4217 code for the Mexican peso.
"es-MX" — [L], and — unlike the Philippines example — there is no open question to flag on the default-language choice itself. Per an internal Advisor review, Spanish for Mexico is "full stop" and the top-ranked language across all five target countries — there is no PhilHealth-style "is English good enough" question here, because English is not a viable clinical-charting default for Mexico at all. The open question is not which locale but when the product may show it: the product ships English-only for every screen until that screen's language has a named clinical reviewer — so es-MX is the correct value for this field today, but it does not by itself authorize turning Spanish on anywhere. That gating is a separate, already-documented mechanism, not something this field changes.
NEEDS LOCAL INPUT — not assumed, despite an available guess, for the same reason the Philippines example declined to assert one: this is the field the template itself calls out as "patient-safety-adjacent... do not assume." An uncertain guess is that Mexican administrative and clinical forms commonly follow DD/MM/YYYY (consistent with general Latin American and European-influenced convention, and distinct from the Philippines' own US-influenced guess of MM/DD/YYYY) — but this is not asserted. The precise question: what date format does an actual IMSS, ISSSTE, or SSA claims/reporting form, or a NOM-024-conformant clinical record, actually use?
NEEDS LOCAL INPUT, for the same reason as date_format. A mild, unconfirmed expectation is that Mexico follows 1,234.56 (comma-thousands, period-decimal, the same convention as the US and the Philippines' own guess) rather than the reversed convention common in continental Europe and much of South America — but a decimal-point misread in a dose or lab value is a safety error, and this expectation is not a substitute for checking an actual Mexican lab report or prescription template.
NEEDS LOCAL INPUT. No Mexican data-residency mandate for health data specifically, analogous to China's PIPL/DSL, is known — but "not aware of one" is not the same as "confirmed none exists," and Mexico-specific research here was shallower than the Philippines research, not deeper. The precise question: does LFPDPPP, LGPDPPSO, or a sector-specific health-data regulation impose any residency or cross-border-storage condition, and — given the Field 3 question above — does the answer differ for a public-sector (LGPDPPSO) deployment versus a private one?
NEEDS LOCAL INPUT, with a lean toward None, for the same reason as the Philippines example: no enumerated, HIPAA-Safe-Harbor-style de-identification standard published for Mexico by any federal body (INAI or the Secretaría de Salud) is known. If a Mexican health-IT or legal contributor confirms none exists, the honest value is None — matching both the xx stub's and the Philippines example's own convention that "no known standard" is a real, valid answer.
NEEDS LOCAL INPUT, with a lean toward None for the same reason as Field 14: no published INEGI (Instituto Nacional de Estadística y Geografía) or Secretaría de Salud small-cell suppression rule for health statistics is known, but its absence has not been confirmed, and confidence in "not aware of one" is weaker here than for the equivalent Philippines question, simply because less time went into Mexico-specific search on this particular field.
[L], lower confidence than the Philippines example's equivalent answer. Mexican health research is generally understood to operate under Comités de Ética en Investigación (research ethics committees) and, for certain protocols, a Comité de Investigación, both typically required to be registered with COFEPRIS (Comisión Federal para la Protección contra Riesgos Sanitarios) under the Ley General de Salud's research provisions — but unlike the Philippines' PHREB, no single national accrediting body can be named with confidence, nor which committee type gates which kind of secondary use. A starting, more hedged value than the Philippines example's: ("Comité de Ética en Investigación", "COFEPRIS-registered"). NEEDS LOCAL INPUT: the exact committee structure and naming actually used, whether COFEPRIS registration is a hard precondition for the specific secondary-use scenarios this field would gate or only for interventional research, and — again per the Field 3 public/private question — whether a public-sector institution's internal ethics/research committee follows a different accreditation path than a private one's.
Summary: what this worked example proves and what it does not
Proves: the template holds up on a genuinely harder case. Every one of the 17 fields got an entry here too, and — unlike the Philippines pass — this example surfaced a structural open question (Field 3: which of two parallel privacy statutes governs, keyed to public-versus-private ownership) that the template's per-field structure does not have a slot for on its own.
Does not prove: that Mexico is ready to ship as a real pack — if anything, this example is less far along than the Philippines one. Of 17 fields, a rough count: 3 are reasonably safe today (pack_id, currency, the two placeholder identifiers), 1 has a confident-enough answer to build on (locale's Spanish default — more confident than the Philippines' own locale answer, but with zero other fields reaching that bar here), and the remaining fields are open, each with a named question — including every field in privacy_regime, all of fhir_profile, and, newly surfaced here, the payer/plan structure (Field 7) and the public/private regime split (Field 3). That lower ratio, on the country that matters more, is itself the most useful fact this document produces: language readiness and regulatory readiness are entirely different axes, and Mexico is far ahead on the first and no further ahead than the Philippines — arguably behind it — on the second.
Three things, discovered only because Mexico is not a single-payer, single-privacy-regime country the way both the US pack and the Philippines example are.
- The template has no field for "which regime applies depends on who owns the deployment." Field 3 (
privacy_regime) assumes one privacy-regime answer for a whole country pack. Mexico plausibly needs two — one for LFPDPPP (private facilities) and one for LGPDPPSO (IMSS/ISSSTE/public facilities) — selected by a fact about the installing institution, not about the country. The interface, which maps onepack_idto one privacy regime, has no seam for "one country, two regimes, chosen at install time." It is worth the template or the interface saying explicitly whether a country in this position gets two packs (mx-private,mx-public) or one pack with an install-time regime switch. - The template's per-field "where the answer comes from" guidance assumes a single named national authority exists per field, and Mexico's fragmentation breaks that assumption for
payer_plan_vocabularyspecifically. The US has two payers to name; the Philippines has one; Mexico plausibly has three-to-five (IMSS, ISSSTE, the reorganized uninsured-population programme, and possibly military/Pemex systems). A country with a fragmented public system needs the template to say "list every major public payer separately, and expect more than one" rather than implying a single authoritative source. - A stale-citation risk that neither existing example needed to surface: NOM-024-SSA3-2012 is named confidently in this project's own internal review, but its year (2012) is old enough that whether it is still the current version of that standard is itself an open question. The template does not currently prompt a contributor to ask "is the regulation I am citing still in force, or has it been superseded," for any field, and probably should — especially for a country pack built years after this initial one.
Nothing needed extending. The Spanish interface catalogue was checked against the English one key-for-key: both carry exactly the same five keys with no gap in either direction — the Spanish catalogue is already a complete 1:1 translation of the only screen currently registered in the project's own catalogue-completeness test.
The layout risk, as already documented: of the five converted strings, the "Chart activities" heading ("Actividades del expediente", +59% length) is the tightest fit — a single-line uppercase rail heading in a narrow column — and is flagged as the one most likely to wrap or truncate. A system-note string grows more in absolute percentage (+89%) but is already a wrapping multi-line note, so the growth is absorbed rather than truncated. The other three strings have room.
No Spanish was newly written for the interface catalogue, because none was needed. Where Spanish terms appear above (CIE-10, NOM-024-SSA3-2012, LFPDPPP, LGPDPPSO, IMSS, ISSSTE, Comité de Ética en Investigación), they are proper names/acronyms of real Mexican instruments and institutions, not translated interface copy, and are not native-Mexican-Spanish-reviewed prose — a native Mexican Spanish speaker with clinical or legal background should confirm even the acronym expansions given here before they are trusted.