The first page for your clinic

A clinic with no developer: You want to run a clinical record system but cannot hire a full-time software engineer. This guide tells you what you need to hire locally and what your local team actually does.

A clinic hiring a local developer: You have found someone. This guide describes three separate jobs, what skills each one needs, and how to check each one was done right.

A developer or ministry team evaluating the software: You want to know what exists, what does not, and how long it really takes to adapt it for your country. This guide says plainly which parts are quick, which are not, and what you need to research before coding begins.

blueOpenHealthcare is a free, source-available clinical platform for eligible countries: patient records, terminology, registration, scheduling, clinical notes, orders, results, medicines, lab, and imaging — eight clinical products in one launcher. It is built to be adapted for your country — you change the coding systems (ICD, SNOMED, LOINC, drug codes), the privacy consent text required by your law, how long records stay, whether data may leave the country, and your language. The software runs only on synthetic data right now and refuses to start unless you tell it so explicitly. Share-back means registering each live clinic and sending back the code changes and translations you made — never patient data. The licence terms are still with counsel.

The eight separate clinical products are decided into the free edition for eligible countries, pending safety review; the installer image today contains the platform modules only, with the eight products to follow.

Step 1: Understand

• Read the country readiness checklist: start here. It names every question your team needs to answer about your country's coding systems, privacy law, and clinical workflows.
• Read the two-day timeline guide in the developer kit. It tells you what is actually easy and what is not.
• Use the template to map out what you know and what you need to research.

Step 2: Prepare

• Work with your legal team to answer the regulatory questions: consent text, data retention, data residency, which coding systems your country requires.
• Document the coding systems your country uses (ICD version, SNOMED variant, LOINC, drug codes, procedure codes).
• Complete the jurisdiction pack template: the template is here. Every field should have either a sourced answer or a NEEDS LOCAL INPUT question. Never guess a regulatory fact.

Step 3: Adapt

• Hire a local developer to code the jurisdiction pack from your completed template.
• Use the developer kit tools to load your coding systems and run tests.
• Translate the user interface if needed. The developer kit has extraction tools and a checklist.
• See how to hire and what to ask for.

Step 4: Run

• Run the clinic installer: a script that boots the platform in a Docker container on a Debian or Ubuntu server. The installer comes inside the free-edition source package, which is available on request — see the downloads page.
• Verify it with the installer's own health checks — it will refuse to say success until every module responds.
• Log in, test with synthetic data, train your staff on the interface.
• Real patient data is not possible yet, and the software will not let you. Access control by care team is now enforced for every clinical record type. The software still refuses to start outside the synthetic-data posture until an operator explicitly records a go-live sign-off — a named person and a time — and that should not happen before the rest of the go-live checklist is done. Plan your pack, your translation and your training now; the decision to allow real data is not a setting you turn on lightly, it is a deliberate act we ask you to make and record.

If you run this for real patients, share back what you build. This means:

• Register each clinic that goes live — give us a clinic name and a country, nothing else.
• Send back the code changes you made (new jurisdiction pack, bug fixes, features).
• Send back any translations you created.
• Never send patient data, screenshots, or identifiable anything. Share-back is about the software and the language, not about your patients.

This is how the software reaches developers and clinicians who already move between health systems in two countries — exactly the people best placed to teach us what each country's coding, privacy law and language actually require.

Eligibility is based on the World Bank's country income classification, published yearly. Low-income and lower-middle-income countries are eligible automatically. Upper-middle-income countries may apply; MOBLUEHQ decides case by case. High-income countries (Canada, the US, Europe, Australia, Saudi Arabia) need a commercial licence.

If your country is not eligible for the free edition, you can still:

• Work with us on a licence before building on it — the terms for everyone outside the free edition are on the licensing pages.
• Contact us about a commercial licence: healthcare contact.
• See the full eligibility rules: eligibility and share-back.

Q: Does the software stay in our country?

A: Yes, if you run it locally. The default install has no outbound network calls for data. Your patient data stays on your machine or your clinic's network. You decide whether to add external backups, terminology services, or health information exchange connections. The software does not decide this for you.

Q: What leaves the system and where does it go?

A: Nothing, by default. If you add cloud backups, terminology lookups, or links to a national health exchange, those are your choice. The software itself starts with zero outbound connections.

Q: Who can see patient records?

A: The software has role-based access control built in. You define which staff members can see which patient records, and the system enforces that when they log in. Care-team-scoped access control — restricting a user to records for patients on their own care team — is enforced for all fifteen clinical record types today (Encounter, Observation, ServiceRequest, DiagnosticReport, MedicationRequest, Specimen, Patient, MedicationAdministration, DocumentReference, Condition, AllergyIntolerance, Procedure, Immunization, Communication, RelatedPerson). The software proves which access happened through signed receipts, which record writes and their timing; reads are recorded in audit events.

Q: What does a signed receipt prove?

A: A receipt proves what the software ran and recorded — exactly which code was executed, what data was changed, and when. Receipts are generated on writes; reads are recorded as audit events. It does not prove the underlying clinical claim is true. A drug interaction, a diagnosis, a lab result — these are real-world facts about the patient, and the software is not the authority on any of them. A named clinician remains the only decision authority. The receipt proves the software did what you asked it to do, and did it correctly.

Q: What if we stop paying attention to it?

A: The software is not a monthly subscription. Once installed, it runs on your hardware and your network. There is no cloud dependency. You can use it indefinitely without calling home. If you want to upgrade, security patches, or new features, you manage those yourself — there is no automatic update.

Q: Can we fork it and customize it for us?

A: Yes. The source code is yours to read and modify. The licence says you can use it locally, and if you run it for real patients, you share back the changes you make. You cannot lock it up or claim it as your own product, but you can adapt it.

Q: Who is liable if something goes wrong?

A: This question belongs to your lawyer and your local regulations. The software carries no liability warranties — it is free and source-available, and the licence (which is still being drafted) will state this plainly. A named clinician is the decision authority in every case, and your clinic is responsible for how it is used. This is not a question the software answers; it is a question your country's law and your clinic's policy answer.

Q: Is this clinically validated or HIPAA-compliant?

A: The software makes no such claims. It is source-available and free for eligible countries. No regulatory body has approved it. No clinical trial has validated it. Do not assume that something works in the US or one clinic will work in yours without adaptation. Before using it with real patient data, consult your local healthcare regulator, your health ministry, and your legal team.