Country pack template — how to adapt blueOpenHealthcare to your country
Who this is for: a clinician, health-information-management professional, or health-IT lead who knows their own country's rules and wants to tell us what a version of this software for their country would need — not someone who already knows this codebase. You do not need to write code to be useful here. Answering the questions below, precisely, is the contribution.
What this is not, yet: a way to submit anything. As of 2026-09-12, the licence and contributor terms for this project are still drafts sitting with counsel and are not in effect. This template exists so that when they are, "contribute a country pack" is a task with a clear shape instead of an invitation with no on-ramp. Read this, work through it for your country if you want to, and hold on to your answers — or send them wherever the project names once the terms are published.
The one rule that matters more than any field below
Never guess a regulatory fact. If you do not know, with a source you could point to, exactly what your country's law or a national body requires — the number of years records must be kept, the wording a consent notice must use, whether data may leave the country — write NEEDS LOCAL INPUT and the precise question that would resolve it. A specific, well-formed question is the valuable output. A plausible-sounding invented answer is the single worst thing this template can produce, because software will be configured on the strength of it. Nobody will fault you for not already knowing something that requires a lawyer, a regulator's published guidance, or a national body's own documentation to answer correctly. Everybody will be worse off if a wrong-but-confident answer ships.
This is a second implementation of an interface that already exists and already has one real example. Read these first, in this order, so you build on them rather than duplicating or contradicting them:
interface.py(same folder as this file) — the actual shapes you are filling in:JurisdictionPack(the container) and three "Protocols" —CodingSystem,PrivacyRegime,FhirProfile— that a country pack must answer.- The US pack (same parent folder) — the one real, filled-in pack that exists today, built around current US law and coding systems. It is the worked example this template is modeled on. Where this template says "see how the US pack answers this," read that folder's files for the shape of a real answer, not to copy its content.
- The stub pack — a deliberate stub, not a real second country. It exists to prove the mechanism works, not to model what a real pack looks like. Do not use it as your example; use the US pack.
Every country pack is a fixed list of 17 answers (12 general fields plus 5 added for data-sharing/de-identification rules). Nothing is optional and nothing may be copied from another country's pack "to fill the gap" — an unanswered field is NEEDS LOCAL INPUT, never a value from another country with the serial numbers filed off.
pack_id — a short code name for your packWhat it is: A short lowercase identifier, e.g. "us", "ph", "mx" — usually the ISO 3166-1 alpha-2 country code. This is a naming choice, not a legal fact.
If you get it wrong: Nothing regulatory — but a confusing or non-standard code makes the pack hard for others to find and reference. Prefer the standard two-letter country code.
Where the answer comes from: The ISO 3166-1 alpha-2 list.
coding_system — which clinical vocabularies your country's records useWhat it is: Which vocabulary (diagnosis, procedure, lab result coding systems) and which specific system identifier your country's providers, payers, and regulators actually expect.
If you get it wrong: This is not a cosmetic error. A record coded in the wrong vocabulary cannot be submitted to your country's insurer or public-health reporting system, and may misrepresent a diagnosis or procedure to another clinician reading the chart. Getting this wrong is a claims-rejection and patient-safety issue at once.
Where the answer comes from: Your country's national or social health insurer's own technical/claims specification is usually the most authoritative source. Your Ministry/Department of Health's statistical-reporting standard is the next most authoritative. If your country has not published either, that gap is the answer: NEEDS LOCAL INPUT, with the question named precisely.
privacy_regime — consent language, retention rules, and export rulesThree separate things, each with its own method:
The actual words a patient reads before their data is used, for each of (at least) "clinical care," "secondary use" (research, analytics — anything beyond direct care), and "research" specifically. This is legally operative text, not marketing copy. Never draft this yourself from general knowledge — a wrong or incomplete consent notice can invalidate the consent it is meant to obtain. This is a question for a lawyer licensed in your country, or your data-protection regulator's own published model language if one exists.
How long, by default, each kind of record (a patient's demographic record, an encounter, a lab result) must or may be kept, in days. Do not average, round, or estimate this number. If your country's rule is "at least 10 years," the field is 10 years in days, cited to the regulation.
In plain language, what must be true before data may leave the institution (or the country) for a given purpose. This is usually where your country's cross-border-transfer rule lives.
If you get any of these wrong: Consent: a patient may not be validly informed. Retention: records destroyed too early can be a compliance violation; kept too long can itself be a violation. Export: data can leave the country in a way that breaches the law, with the institution liable.
Where the answer comes from: Your country's data-protection law and the regulator that enforces it. Retention specifically is often set by a separate health-records or medical-practice regulation.
fhir_profile — which technical shape of a health record your country expectsWhat it is: FHIR R4 is the fixed international data format this project uses everywhere; what varies by country is the profile — a stricter set of rules on top of R4 that your country's health authority may publish, the way the US publishes "US Core."
If you get it wrong: If a real national profile exists and you ignore it, records may fail validation against systems that expect the national profile. If none exists yet, inventing one creates a shape nothing else recognizes.
Where the answer comes from: Your Ministry/Department of Health or national digital-health agency's own published implementation guide, if one exists. If none exists, say so — that is itself useful information.
compliance_rule_set / policy_pack_format — placeholder identifiersWhat they are: Short string names the addendum reserves for a compliance-rule engine and criteria/policy-pack format that do not exist anywhere in this codebase yet, for any country, including the US. Every pack today, including the US pack, fills these with a placeholder name of the shape "<country>-<something>-v1".
If you get it wrong: Nothing breaks today, because nothing reads these fields yet. Do not spend real effort designing a rule engine here — that is future work.
Where the answer comes from: Pick a short, honest placeholder name (e.g. "ph-dpa-v1"), and say plainly that it is a placeholder, not a built mechanism.
payer_plan_vocabulary — the names of your country's insurers/payer categoriesWhat it is: The list of payer or plan names/categories a record or claim in your country would actually carry.
If you get it wrong: A payer field that does not match what your country's claims actually say makes claims data harder to route, report, and reconcile.
Where the answer comes from: Your national social/public health insurer's own name, plus whether your country's claims distinguish private-insurer, employer-sponsored, and self-pay categories the way some countries do, or categorize differently.
currency — your country's currency codeWhat it is: The three-letter ISO 4217 currency code (e.g. USD, PHP, MXN).
If you get it wrong: Amounts display in the wrong currency, which is confusing but not generally a compliance issue at the display layer.
Where the answer comes from: The public ISO 4217 list. This is one of the few fields on this list that is a simple, low-risk lookup.
locale — the language/region tag your interface defaults toWhat it is: A BCP-47-style tag (e.g. en-US, en-PH, es-MX) describing the default language and regional conventions.
If you get it wrong: The interface greets a clinician in a language or convention that does not match their workplace's actual working language.
Where the answer comes from: What language clinical documentation, IT systems, and national-insurer paperwork actually use in your country today — not what is spoken at home, and not an assumption.
date_format — how dates are written and readWhat it is: The convention your country's clinical and administrative documents actually use — MM/DD/YYYY, DD/MM/YYYY, YYYY-MM-DD, or something else.
If you get it wrong: This is a patient-safety-adjacent field. A date misread because of a swapped day/month convention can misdate a lab result, a medication order, or a birth date.
Where the answer comes from: The actual format used on your national insurer's claims forms and your health ministry's official reporting forms. Check the form itself; do not assume from general convention.
number_format — how numbers are written (decimal and thousands separators)What it is: Whether your country writes "one thousand two hundred thirty-four and fifty-six hundredths" as 1,234.56 (comma thousands, period decimal) or 1.234,56 (the reverse), or another convention.
If you get it wrong: A misread decimal point in a dose, a lab value, or a lab reference range is a direct patient-safety error.
Where the answer comes from: What convention appears on official lab report templates and prescription forms in your country. If uncertain, this is worth a NEEDS LOCAL INPUT rather than an assumption.
data_residency_flags — informal notes on where data must physically stayWhat it is: A short list of free-text flags describing any requirement (or the deliberate absence of one) that data stay within your country's borders, or within specific approved locations.
If you get it wrong: If your country requires in-country storage and this is left unset, an institution could unknowingly violate that requirement. If your country has no such requirement and this is set anyway, it can impose unnecessary operational cost.
Where the answer comes from: Your data-protection law and any sector-specific health-data regulation, specifically sections on data transfer, outsourcing, and cloud/third-party processing.
secondary_use_allowed — can data collected for care be reused for something else?What it is: A plain true/false for whether your country's law permits, by default, patient data collected for direct clinical care to be reused for a secondary purpose (research, population-health analytics, quality measurement) without a fresh, purpose-specific authorization from the patient.
If you get it wrong: Setting this true when your law requires purpose-specific consent enables data reuse the software has no legal basis for. Setting it false when your law permits broader default reuse under-serves legitimate public-health and research use your country actually allows.
Where the answer comes from: Your data-protection law's own treatment of "further processing" or "compatible purpose," and any sector-specific health-research law.
deidentification_standard — the name of a standard for stripping identifying dataWhat it is: The name of a specific, defined method your country's law or a national body recognizes for removing (or a formal process for making) health data "no longer personal data."
If you get it wrong: Claiming data is "de-identified" under a standard that does not actually apply, or does not exist, in your country is a false compliance claim with real legal exposure.
Where the answer comes from: Your data-protection regulator's own guidance. Many countries' data-protection laws do not name a specific technical de-identification standard. If that is true of your country, the honest value for this field is None.
small_cell_threshold — the smallest group size safe to report a statistic aboutWhat it is: In public-health reporting, a count below some small number is often considered re-identifiable. This field is that minimum safe count for your country, if one is defined.
If you get it wrong: Reporting a statistic based on too few individuals can re-identify a specific patient even though no name was shown — a real privacy breach.
Where the answer comes from: Your national statistics agency's own disclosure-control standard for health data, or your health ministry's own small-numbers reporting rule. If none is known to exist, None is the honest answer.
data_residency_required — a plain yes/no on the same question as Field 12What it is: Where Field 12 is free-text notes, this is the single true/false a program can branch on: does your country legally require health data to stay within its borders?
If you get it wrong: Same consequence as Field 12 — this is the boolean a real enforcement check would actually read, so getting it wrong here matters.
Where the answer comes from: Same source as Field 12 — keep the two consistent with each other.
approval_body_types — which committees or boards must approve a secondary useWhat it is: The names of the kind(s) of body that must approve a secondary use of data before it may proceed.
If you get it wrong: Naming the wrong body (or none, when one is legally required) means a workflow that should stop for approval will not, or will stop for an approval process that is not actually the one your country requires.
Where the answer comes from: Your country's national health-research ethics authority (many countries have one national accrediting body for institutional ethics review committees) and your data-protection regulator, if it separately requires its own sign-off.
When you are done: You will have, for most fields, either a sourced answer or a NEEDS LOCAL INPUT line with a precise question. Both are the deliverable. See the worked examples in this folder for what a filled-out template actually looks like, including how many fields it is honest to leave as open questions on a first pass.