Contribute

What's possible now, and what waits on counsel

Open — home Why Licensing Contribute Governance Security Roadmap Community

No real patient, member, claimant or clinician data of any kind — identifiable, de-identified, “anonymised”, aggregated, or screenshot — may be posted, attached, or committed anywhere in this community. Synthetic, generated fixtures only. This covers generated synthetic data only — "de-identified" real data is banned too, because a community has no way to verify a de-identification claim.

The repository is private

There is nothing public to clone or download today. The licence and contribution terms are being decided by counsel; code contributions open when they are published. Until then, contribution means reading, writing, and discussing — not code.

Now — what you can do today, locally

Adapt it for your own clinic or country. The developer kit ships in starter/ with eight tools you run on your own machine: generate a country pack, validate it, load a coding system, build synthetic fixtures, import CSV patient data, and translate one screen at a time. Your changes stay in your own checkout. The kit includes a field-readiness guide, a hiring guide, and step-by-step prompts for each task. Start with bash starter/scripts/check_prereqs.sh to verify your environment.
Use the scripts/devkit/ tools:
- new_country_pack.py — generate a jurisdiction pack for your country (coding systems, privacy rules, FHIR profile)
- validate_pack.py — verify a pack satisfies the interface
- make_fixtures.py — generate deterministic synthetic patient data
- load_coding_system.py — load your country's clinical vocabularies (ICD, SNOMED, drugs, etc.)
- import_csv_patients.py — import patient demographics from CSV
- translation_kit.py — export/import UI translations per locale
- doctor.py — diagnose environment setup issues
- quickstart.sh — verify all tools work end to end
File a field report. Tell us what your country's coding system, privacy law, FHIR profile, currency, locale, or payer vocabulary would need to be, using the field-report template. Text only. Send it through contact.
Translate one screen into your language. An i18n scaffold exists in the platform web app with one lookup function, one catalogue per locale, and a completeness test. Today the catalogue holds 52 English keys, covering the navigation rail, the top bar, the patient banner labels and the purpose-of-use screen. Export them as a spreadsheet with scripts/devkit/translation_kit.py export, translate in any spreadsheet application, and bring them back with translation_kit.py import, which refuses a file with a missing key, an empty value or a broken placeholder and names the row. translation_kit.py status tells you how complete a language is and whether it is registered — an unregistered language is not shipped, however complete it is. Clinical content (drug names, lab codes, diagnoses) never goes through this catalogue — they stay in the terminology service and are always in the original language until a named clinical reviewer in your country signs off on a translation. A half-translated screen is worse than English-only, so translation waits on that review.
Read and argue with the design. The specs are written to be read; disagree with a field's shape, and say why. Send feedback through contact.

The fastest way to start: adapt it for your clinic right now

Your clinic can start using blueHealthcare for your own patients today by generating a jurisdiction pack for your country and running the platform locally. The tools are in starter/scripts/ and scripts/devkit/ — download the source, run the prerequisite checker, and follow the prompts. Your changes are yours; they stay on your machine. When and if you later choose to share them, you do so on your own terms (source-available rules apply). No upstream contribution path exists yet.

If you want to contribute those changes back later, when the licence and inbound terms are published, the shape is already settled: read what a pack needs to answer, and you'll have a clear picture of the work. Internally, we've worked one pack as far as general research can take it without a local expert — eighteen fields that need someone who knows that country's health-IT rules, claims process, or privacy-authority practice to answer. One correct answer to one field, supplied as a field report, is a real contribution today — you don't need the whole pack. Send it through contact.

Later — once the licence terms are published and a contribution path opens

We cannot accept contributions yet. When the licence and inbound-contributor terms are published — they are with counsel, and no date is set — a pull-request process will exist. At that point, you may send:

A jurisdiction pack (a new core/jurisdiction/<xx>/ directory implementing the three Protocols), shipped with a synthetic fixture and passing the interface's own test.
A terminology or coding-system adapter — pointing at a national terminology server by URI, never committing a licensed vocabulary's own code tables into the repository.
A privacy-regime module, reviewed by an in-country reviewer before it is submitted.
A translation of one or more screens, with a named clinical reviewer in your language who has signed off on the clinical content.
An extension to the test suite that proves your change, falsifier-first (you write the failing test before the fix).

Until that path opens, your work stays local. What you may do with your changes — including whether you may pass them to anyone else — depends on licence terms that are still with counsel, so check with your own lawyer before you rely on it. Send field reports and design feedback now through contact.

The developer kit (ships with source)

The developer kit — source code, synthetic demo data, eight command-line tools, and a sandbox — ships with blueOpenHealthcare in the starter/ directory. The tools live in scripts/devkit/ and are ready to use. Start with bash starter/scripts/check_prereqs.sh to verify your environment, then bash scripts/devkit/quickstart.sh to verify all tools work end to end. The starter/README.md and step-by-step prompts in starter/prompts/ walk you through the most common tasks: country pack generation, translation extraction, and synthetic data creation.

What we will not accept, now or later

No LLM anywhere in an extraction or coding path — a model choosing a diagnosis code, a coverage rule, or any clinical fact from free text is exactly the failure mode this project exists to refuse.
No clinical content translated without a named clinical reviewer for that language. A fluent, unreviewed translation of a clinical term is a plausible-looking error, which is worse than an obviously missing one.
No invented regulatory fact. A field report or a pack that states a country's law or coding rule without saying how confident it is, or where it came from, will be sent back marked NEEDS LOCAL INPUT rather than merged as stated.
No patient data, ever — real, de-identified, or "anonymised" — repeating the rule above because it is the one rule that never bends.
No feature that lists, browses, requests, or sells data or access to data, in any form, regardless of code quality. This is a scope boundary, not a review comment, and a proposal can be closed on scope alone.

What accepting your code will oblige us to do

Once inbound terms are published, merging a contribution is not a one-time favor to the contributor — it is the company taking on maintenance and security response for that code, indefinitely, and a jurisdiction pack someone contributes may end up configuring a system used on real patients in their country. That is why review is slower than the pull request looks like it deserves, and why a falsifying test is asked of the contributor, not written for them afterward.

How long you'll wait

We can't commit to a response time today — there is no named maintainer yet to hold to one (see community). Say so plainly rather than imply a turnaround we might miss: expect silence to mean "not yet read," not "declined," until a maintainer and a stated reply window exist.