-
Notifications
You must be signed in to change notification settings - Fork 1
Home
This wiki is the working documentation for openrunic: what it is, how it is built, and how to work on it. It is for contributors, for people evaluating the project, and for anyone who wants to understand a decision without reading the whole repository.
openrunic is an open-source operating system for human health. The first product is a modern, fast, lightweight electronic medical record: patient demographics and registration, scheduling, clinical encounters and documentation, orders and results, and the revenue cycle from charge capture through remittance.
It is built by Yosemite Crew, the team behind the open-source operating system for animal health, applying the same approach to human healthcare: open standards, a fast and pleasant developer experience, and software a clinic of any size can run itself.
It is licensed under AGPL-3.0-only. If you run a modified version as a network service, the licence requires you to offer its source to your users.
The project is organised around three audiences, and every surface belongs to one of them.
Hospitals. Practice management, scheduling, encounters, and clinical workflows for care teams. Today this is apps/web, a 26-route staff application.
Patients. Patient-facing access to appointments, records, and communication. Today this is an early apps/portal on a feature branch.
Developers. A clean FHIR R4 API surface and typed packages so others can build on top. Today this is apps/api plus the workspace packages.
Pre-alpha. APIs, schemas, and package boundaries will change without notice. Do not run this in production, and do not put real patient data into it.
Being specific about what exists is more useful than a label, so:
| Area | State |
|---|---|
| Monorepo, CI, governance, ADRs | Merged to dev
|
@openrunic/types, @openrunic/fhir (23 mapper pairs, round-trip tested) |
Merged to dev
|
@openrunic/database (47 models, 59 enums, tenant scoping, audit chain, form promotion, deterministic seed) |
Merged to dev
|
@openrunic/ui (22 components, Storybook, 95 percent coverage floors) |
Merged to dev
|
apps/api foundation: middleware chain, error contract, OpenAPI, FHIR Patient, internal patients and appointments |
Merged to dev
|
apps/web: the 26-route staff application in mock mode |
On the feat/emr-app branch, not yet merged |
apps/portal: the patient portal |
Early work on the feat/patient-portal branch, not merged |
@openrunic/x12, @openrunic/forms-engine, @openrunic/terminology, @openrunic/adapters
|
Early work on the feat/emr-packages branch, not merged |
| Self-host packaging (container images, boot-time migration) | Early work on the feat/ops-selfhost branch, not merged |
| Postgres row-level security | Designed and documented, not enabled |
| Authentication | Stubbed behind a resolver interface. No real token verification yet |
| Backup and restore tooling | Not started |
Pages in this wiki mark anything that is not merged. Where a page and the repository disagree, the repository is right.
Relational storage, FHIR at the edge. PostgreSQL managed by Prisma is the single source of truth. FHIR R4 serialisation happens at the API boundary, and every mapped resource ships with round-trip tests. See FHIR boundary and ADR-0002.
Audit is structural, not additive. AuditEvent was the first model in the schema. Events form a per-tenant SHA-256 hash chain, so tampering with history is detectable. See Audit and hash chain.
New here? Read Getting started to get the app running, then Architecture overview for the shape of the system. Keep Glossary open if the clinical and billing vocabulary is new to you.
Making a change? Development workflow covers branches, commits, and pull requests. Testing strategy and Code quality bar cover what has to be true before it merges. Troubleshooting covers the traps that cost people an afternoon.
Working on a specific area? Data model, API design, Web app, and Component library each go deep on one part.
Evaluating the project? Compliance posture states plainly what openrunic is not. Security and supply chain describes the controls. ADR index records the decisions and what was rejected.
Two rules apply to everything in and around this project, without exception.
Synthetic data only. No real patient data anywhere: not in issues, pull requests, commit messages, code, tests, fixtures, seed data, screenshots, or logs. Use obviously invented identities such as "Testina Patientsson" with MRN OR-100482. Anything containing real data is scrubbed on sight and treated as an incident.
Never commit secrets. Only .env.example files with placeholder values belong in git. If a secret leaks, rotate it immediately and tell the maintainers. Removing the commit from history is not enough.
openrunic is an open-source operating system for human health. Pre-alpha: do not run it in production, and never put real patient data into it.
Repository · Licence (AGPL-3.0-only) · Security policy · Contributing · Code of conduct
Where this wiki and the repository disagree, the repository is right.