China (`cn`) — a filled-out country pack
Status: a starting point, not a finished pack — and, more than either prior example, a starting point for a decision about whether to proceed at all, not just a technical draft. This is one contributor's attempt to fill in the template for China using only public, primary-source material where available, this project's own prior internal review, and secondary legal analyses of Chinese law where no primary-source English text was found — without a lawyer, a Chinese health-IT specialist, or PRC counsel. Every answer below is tagged for confidence, same convention as the Philippines and Mexico examples: [L], [SAFE], or NEEDS LOCAL INPUT. This example uses the corrected field numbering explained in the India example's header (1–17 matching the interface's actual order, including field 13, secondary_use_allowed, which both prior worked examples omitted).
Why China is not like the other four, stated before the fields rather than buried in them: every other country in this batch of five (Philippines, Mexico, India, Jamaica) has an open regulatory-detail problem — which code edition, which consent text, which date format. China has that same problem plus a structural one none of the others do: its data-protection law's plain, well-documented default is that certain data must stay inside the country, and the mechanism this project's own draft licence relies on to track a deployment (a "share-back" registration) is exactly the kind of data-leaving-China question that regime is built to catch. Said plainly, because it must be said plainly, not softened into a needs-local-input marker: a MOBLUEHQ-hosted or cloud-connected version of this software is, on the evidence below, likely to be legally hard to operate for a Chinese deployment in a way that is not true of the Philippines, Mexico, India, or Jamaica. The project's own on-premise, no-telemetry architecture is very plausibly the only shape that avoids the problem — that architectural fact, not a licence clause, is what makes a China deployment possible at all, and this project's own internal review already reaches the same conclusion: "the on-premise, no-telemetry architecture satisfies all of it by construction." This example does not relitigate that review; it verifies its coding/administrative fields against the template and adds citations where better primary or secondary sources could be found.
"cn" — [SAFE], ISO 3166-1 alpha-2 for China.
system_id(): not yet named — depends on the answers below.- Diagnosis coding — [L], NEEDS LOCAL INPUT for the operative claims/reporting detail. China's own national standard for disease classification and coding is GB/T 14396 ("Classification and Codes of Diseases"), described in the academic and technical literature as an expanded, China-specific clinical modification built on WHO ICD-10, with a GB/T 14396-2016 revision named as the current edition in more than one source checked (a BMC Medical Informatics article on Chinese ICD-10 coding tooling, and a PMC comparative-classification article) — [L], sourced to academic literature describing the standard, not to the standard's own published text. ICD-11 adoption is NOT confirmed at national scale, named here precisely so it is not misread as support: a search surfaced a peer-reviewed feasibility study titled an "ICD-11 pilot in West China," which is exactly what its title says — a pilot study in one region, not evidence of a national transition. Treating a regional research pilot as "China has adopted ICD-11" would be exactly the kind of invented-fact error this template exists to prevent. The precise question: which edition of GB/T 14396 (or a successor) does the National Health Commission (NHC) require for claims under China's DRG (diagnosis-related group) payment reform, and has any ICD-11 transition begun outside research settings?
- Procedure and lab coding — NEEDS LOCAL INPUT, no confident answer for either. No primary or reliable secondary source was found identifying China's national procedure code set for claims, or whether NHC mandates LOINC (proposed here only as the same reasonable, unconfirmed default the Philippines, Mexico, and India examples propose) or a domestic lab code list.
- A category the baseline three do not name, and which China's own system makes unusually important: an identifier scheme for the national Resident Identity Card. Every PRC citizen holds an 18-digit national ID number used pervasively, including in healthcare registration ("real-name" registration is standard practice at Chinese hospitals, per general knowledge — [L], not sourced to a specific regulation). The specification's coding-system interface permits a pack to declare categories beyond "diagnosis"/"procedure"/"lab," so an "identifier" category naming the correct FHIR identifier-system URI for this national ID is a plausible fit for a China pack — but NEEDS LOCAL INPUT on whether that Resident Identity Card number is the right identifier for a clinical record at all, versus a separate patient/medical-record number, a health-system design question outside general knowledge.
regime_id():"CN-PIPL-DSL"— [L], naming both instruments because, unlike the Philippines' single DPA 2012 or India's single (if not-yet-fully-effective) DPDP Act, China's data regime for this purpose is genuinely two statutes read together: the Personal Information Protection Law (PIPL), effective 1 November 2021, and the Data Security Law (DSL), effective 1 September 2021. Health/medical information is generally treated as "sensitive personal information" under PIPL, which carries stricter processing conditions — treated here as well-established general knowledge ([L]) but not independently confirmed to a specific article number.consent_text(scope): NEEDS LOCAL INPUT — deliberately not drafted, per the template's own absolute rule and this batch's own practice throughout.retention_default_days(resource_type): NEEDS LOCAL INPUT for every resource type, same five types named in the India and prior examples. No confident figure held or estimated.export_rule(purpose)— the single most consequential answer in this entire document, and the one this document is most confident is directionally correct even without a lawyer's confirmation of every detail. China's cross-border personal-information transfer regime, administered by the Cyberspace Administration of China (CAC), requires one of three mechanisms depending on volume and sensitivity: a CAC security assessment, a CAC standard contract filing, or a personal-information-protection certification — this three-mechanism structure, and the fact that the applicable thresholds were relaxed by the CAC's own Regulations on Promoting and Regulating Cross-Border Data Flows, effective 22 March 2024, is reported consistently across multiple contemporaneous legal-analysis sources (Arnold & Porter, Benesch, Greenberg Traurig) — [L], secondary-source convergent, not read from the CAC's own regulatory text directly. A further Measures on Certification for Cross-Border Transfer of Personal Information, jointly issued by the CAC and the State Administration for Market Regulation, take effect 1 January 2026 — meaning this field's correct answer is moving even as this document is written, a currency risk sharper than any flagged in the Philippines, Mexico, or India examples. Stated plainly rather than deferred entirely to a needs-local-input marker, because the brief instructs it: sensitive personal information (which health data is) triggers the stricter end of these thresholds even after the 2024 relaxation, per the same sources; an architecture that transmits patient-level health data outside China — to a MOBLUEHQ-operated cloud service, for example — would very plausibly need to clear one of these three mechanisms before doing so, and deployment-registration contact data (the kind this project's own share-back model contemplates) is a different, much smaller thing than patient data and should not be assumed to trigger the same mechanism without a lawyer confirming that distinction holds under current CAC rules. NEEDS LOCAL INPUT, with counsel specifically: the exact current volume/sensitivity thresholds (they changed once already in 2024 and a new certification pathway opens January 2026), and whether this project's own share-back contact-data flow is actually exempt from all three mechanisms or merely small enough today to fall under a lighter one.
NEEDS LOCAL INPUT, entirely — with a positive identification of what the real binding constraint more likely is, matching the pattern the Philippines and Mexico examples already found for their own countries. No evidence of a national Chinese FHIR R4 implementation guide was found. What was found, named here because the template's own Field 4 guidance says the real answer is often "a binding technical constraint that is not a FHIR profile at all": China's National Health Commission operates a graded hospital information-system interoperability maturity standard (referred to in the health-informatics literature, in English translation, as something like "Hospital Information Interconnection Standardization Maturity" grading, alongside a separate NHC electronic-health-record adoption grading scale, Level 0 through 8, under which China required tertiary hospitals to reach grade 4 or higher and secondary hospitals grade 3 or higher by the end of 2020) — [L], sourced to academic secondary literature (PMC/JMIR articles on Chinese hospital digital-maturity frameworks) describing NHC's own grading programs, not to NHC's own published standard text. NEEDS LOCAL INPUT: whether either grading scheme specifies a FHIR-compatible or FHIR-equivalent data-exchange requirement a deployment would need to satisfy, independent of whether a formal FHIR implementation guide exists.
"cn-pipl-v1" / "cn-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.
[L], with a staleness warning raised deliberately, on the same basis Mexico's own example raised one for its post-INSABI reorganization. China's public health-insurance system has been substantially reformed and merged over the past decade: the current understanding is that Urban Employee Basic Medical Insurance (UEBMI) covers formal urban employees, and Urban and Rural Resident Basic Medical Insurance (URRBMI) now exists as a merger of what were previously two separate programs (an urban-resident scheme and the New Cooperative Medical Scheme for rural residents) — [L], general knowledge of a reform understood to have occurred roughly in the mid-2010s, not independently re-verified against a current NHC or National Healthcare Security Administration (NHSA) source, and named with exactly this hedge because Mexico's own INSABI-to-IMSS-Bienestar reorganization finding shows how easily a payer name that was correct several years ago goes stale. A starting, deliberately hedged vocabulary: ("UEBMI", "URRBMI", "private", "self-pay"). NEEDS LOCAL INPUT: the current, correctly-named structure as of today, and whether the National Healthcare Security Administration (established 2018, per general knowledge, [L], not independently verified here) publishes its own payer-type vocabulary this pack should mirror.
"CNY" — [SAFE], ISO 4217 code for the Chinese yuan renminbi.
"zh-Hans-CN" — [L], confident on the language itself, with no open question of the kind the Philippines or India examples carry — but with real downstream consequences the locale tag alone does not capture. This project's own internal review ranks Simplified Chinese as needing "full internationalisation," and there is no reason to disagree: Simplified Chinese is unambiguously the working language of Chinese healthcare documentation and IT, the same kind of clean case Mexico's Spanish answer was. What the locale tag does not carry, and what "Limits of the interface" below names explicitly: CJK typography requirements, and family-name-first personal name ordering, which is a real, patient-safety-adjacent detail (a system that renders "given name, family name" for a Chinese patient the way it would for a US one can misidentify a chart) that this container has no field for at all — the same class of gap the India example found for device classification.
NEEDS LOCAL INPUT — not assumed, per the template's own rule for this field and this batch's practice throughout. An uncertain, unconfirmed impression is that Chinese official documents commonly render dates in a YYYY年MM月DD日 (year-month-day, using Chinese characters as separators) pattern consistent with ISO 8601's ordering — [L], not checked against an actual national insurance or NHC reporting form, and therefore not asserted as the field's value.
NEEDS LOCAL INPUT, for the same reason as date_format: a decimal-point misread in a dose or lab value is a direct safety error. A mild, unconfirmed expectation is that Chinese official documents follow the same 1,234.56 convention as the US, Philippines, and Mexico examples' own guesses for their countries when Western/Arabic numerals are used — but this is not a substitute for checking an actual Chinese lab report or prescription template.
The most confident non-[SAFE] finding in this entire document, and it points the opposite direction from every other country examined in this batch of five so far. Unlike the Philippines and Mexico examples, which both found "not aware of a residency mandate, but not confirmed absent," reading PIPL and the DSL together — supported by the CAC cross-border transfer regime described under Field 3 — points to China's default posture assuming in-country storage is the safe baseline and cross-border transfer is the exception requiring one of three CAC mechanisms to clear. [L], and the direction (residency-favoring, not residency-neutral) is about as confident as this template's own convention allows for a field this consequential; the precise legal characterization — whether a given clinic deployment counts as a "Critical Information Infrastructure Operator" (CIIO) under the DSL, which carries the strictest localization obligations, or falls under a lighter general-PIPL obligation — is NEEDS LOCAL INPUT, specifically counsel's. Illustrative flags, not a legal conclusion: ("cn_pipl_dsl_localization_likely", "cross_border_transfer_requires_cac_mechanism").
NEEDS LOCAL INPUT, with the same seriousness the India example gives this field and for the same reason: it is one of the two container slots this codebase actually reads at runtime. No confident answer is held for whether PIPL permits, by default, health data reuse for research or population analytics without fresh purpose-specific authorization — PIPL's general architecture is understood to require purpose limitation and, for sensitive personal information specifically, separate consent for a new purpose ([L], general PIPL-literature knowledge, not independently verified against the statute's own text). The safe interim answer, matching the xx stub's own convention, is false until a PRC-qualified lawyer confirms otherwise.
NEEDS LOCAL INPUT, with a lean toward None for the same reason as the Philippines, Mexico, and India examples: no enumerated, HIPAA-Safe-Harbor-style de-identification standard published under PIPL or by the CAC is known. PIPL does use the concept of "anonymization" as a defined term relieving data of PIPL's own restrictions once achieved, but a defined legal concept is not the same as a defined, enumerated technical standard (the distinction this field asks about) — [L], and PIPL's anonymization definition is not asserted to satisfy this field without a lawyer confirming the two are the same thing this field means.
NEEDS LOCAL INPUT, with a lean toward None, same reasoning as Field 14 and as the other two examples in this batch: no published Chinese national-statistics or health-authority small-cell suppression rule was found.
Best current lean: True. The boolean counterpart to Field 12; per the specification's own consistency requirement, it must agree with Field 12's flags, and Field 12's own finding leans toward a residency requirement existing. NEEDS LOCAL INPUT remains attached to the precise scope (does it bind every deployment, or only those crossing a CIIO or "important data" threshold) — the direction is a confident lean; the boundary is not.
[L], lower confidence than the Philippines' PHREB answer or even Mexico's hedged COFEPRIS answer. China's biomedical research is generally understood to require review by an Ethics Committee (伦理委员会) operating under NHC-issued measures governing life-science and medical research involving human subjects — [L], naming the general concept from lay knowledge of China's research-ethics apparatus, without a confirmed citation to the specific, currently-in-force measure's name or year, not guessed given how directly this example's own Field 3 discussion shows Chinese regulatory instruments have been revised recently. A starting, hedged value: ("Institutional Ethics Committee (NHC-governed)",). NEEDS LOCAL INPUT: the current, correctly-cited governing measure, and whether NHSA (the healthcare-security administration named in Field 7) or the CAC has any separate approval role for secondary use of health data specifically.
The same gap the India example names — no field for "does shipping this feature set make the software a regulated medical device in this jurisdiction" — recurs here with more specificity available. China's National Medical Products Administration (NMPA) issued an Artificial Intelligence Medical Software Classification Guideline on 8 July 2021, read about via secondary industry sources describing software with diagnosis-aiding or deep-learning-based clinical decision support as likely to be classified Class III (the highest NMPA risk tier), while software that only transfers or displays data without analysis is more likely Class II. This project's own decision-support code is exactly the kind of feature this classification guideline targets. This is the same interface gap the India example names, recurring on a second country with sharper, dated evidence — not a new finding about China specifically, but a second, independent data point that the gap is real and not a one-country artifact.
Per this project's own internal review, China is classified upper-middle income under the World Bank's FY2027 country income classification (fetched and read twice by that review on 2026-09-12) and — per that same review's reading of the World Bank's own published 2025 GDP-per-capita figure against the high-income threshold — is within roughly 4% of graduating to high-income, which would remove it from this project's draft eligibility mechanism entirely on a future annual revision. This document did not independently re-fetch the World Bank's classification page today and is relying on that internal, dated, already-cited review rather than repeating the fetch — the same discipline the specification recommends (a pinned, dated snapshot, re-checked at the time of any actual determination, not treated as permanently settled). Trademark first-to-file exposure, US Entity List/export-control screening for any registration handshake with a Chinese hospital, and whether a bulk-sensitive-data rule could apply are all counsel questions this document will not relitigate or restate more confidently than the internal review itself did.
Summary: what this worked example proves and what it does not
Proves: the template can represent a jurisdiction whose primary finding is not "we don't know the answer" (the Philippines' and, mostly, Mexico's and India's pattern) but "the answer is known and it is structurally unfavorable to part of this project's own distribution model." That is a different, harder kind of result for a worked example to produce honestly, and this document tries to state it as plainly as the brief asked rather than hedge it into a pile of needs-local-input markers the way a less consequential finding would be reported.
Does not prove: that China is close to shippable, or that engineering time should be spent on it soon. 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 Simplified Chinese default), 1 has a confident directional answer with an unresolved boundary (data_residency_required/data_residency_flags — confidently True-leaning, unlike every other field in this or the prior two examples, none of which reached even that much certainty on a non-[SAFE] field) — and every remaining field is open, including, again, the live-wired secondary_use_allowed. This project's own internal review already recommended not spending engineering effort on a China deployment until counsel rules on the export/eligibility questions above; this example's own findings support that recommendation rather than complicate it.
Three findings specific to how this example stresses the container differently from the Philippines, Mexico, or India:
- The interface has no field, and per its own scope statement no ambition, to represent "this jurisdiction's data-protection default is incompatible with part of the distribution model the software ships under." Every prior field-level "known limitation" this batch has found (Mexico's two-regimes, India's federated consent, India's multi-language default) is a limitation in how a pack represents a jurisdiction's answer. China's finding is different in kind: it is a limitation in what a pack, however perfectly filled in, can do about a fact that constrains the deployment architecture itself, which is explicitly out of the container's scope — how a host system stores, transmits, or enforces any of this data is a consuming system's job. A perfectly correct China pack would still not resolve whether the software may be run in a MOBLUEHQ-hosted shape at all — the specification is right that this is not its job, but that leaves nowhere in this project's own documentation where a reader learns that a technically-conformant pack does not imply a legally-viable deployment shape.
- Personal-name ordering (family-name-first) has no field. Locale (Field 9) carries a language/region tag but nothing about name-rendering convention, and a system that renders a Chinese patient's name in the wrong order is a real chart-identification risk, not a cosmetic one — the same class of finding as India's number-grouping gap (Field 11), a third instance of "the template's field shape assumes a convention that does not hold everywhere," now spanning number formatting (India), personal names (China), and — per Field 2 above — national-identifier schemes (China again). Three instances across two countries in this batch is enough to call this a pattern, not a coincidence: the template's field-by-field structure keeps finding conventions it did not anticipate needing a field for.
- Eligibility instability is a limit on the licensing mechanism, not the interface, but it changes whether building a
cnpack is worth doing at all — and nothing in either the interface or the template says who is supposed to notice that before work starts. A country pack and a licensing decision are, correctly, kept as separate concerns by this project's own documents. But a pack contributor following the template in isolation has no prompt anywhere in that document to ask "is this country's eligibility itself expected to lapse soon" before investing effort — that check currently exists only because this document could read a separate internal review, which a future contributor without access to this project's internal review history would not have.