-
Notifications
You must be signed in to change notification settings - Fork 1
Compliance Posture
This page states plainly what openrunic is not, what it is designed to support, and the rules that follow. It is for anyone evaluating the software and for every contributor, because two of these rules bind day-to-day work.
The authoritative version is docs/compliance.md in the repository. The posture is deliberately conservative: nothing is claimed that cannot be demonstrated.
Not a medical device. It is not certified, cleared, or approved by the FDA, by an EU MDR notified body, or by any other regulator, and no such certification is implied. It is not intended to provide medical advice, diagnosis, or treatment recommendations.
Not a certified EHR. No ONC Health IT Certification and no equivalent national certification.
Not HIPAA-compliant or GDPR-compliant out of the box. Compliance is a property of a deployment: the organisation, its agreements, its configuration, its operational practices, and its jurisdiction. Source code cannot be HIPAA-compliant by itself, and openrunic is not described that way anywhere. A deployer is responsible for their own obligations, including business associate agreements, GDPR Article 9 safeguards for health data, and any local law that applies.
Not a provider of medical advice. Clinical decisions are the responsibility of qualified healthcare professionals.
If you find wording anywhere in this project that overstates the regulatory status, treat it as a bug and open an issue.
openrunic cannot make a deployment compliant. It is built so a competent deployer can build a compliant deployment on top of it.
Audit logging from day one. AuditEvent was the first model in the schema and the first migration in the repository. Security-relevant actions, meaning who did what to which record and when, are recorded as a core feature. Events form a per-tenant hash chain, so tampering with history is detectable rather than merely discouraged. Access accounting is a baseline expectation in every healthcare regulatory regime. See Audit and hash chain.
Least-privilege access design. Authorization is built around granting the minimum a role needs, and every access decision is auditable. Denials are recorded, not just refused. See Security model.
Encryption guidance, not assumptions. Deployments are expected to use TLS in transit and encryption at rest, at the database or disk level. That is stated explicitly rather than assumed to be a hosting provider's problem.
No telemetry that exfiltrates health data. openrunic does not phone home with patient data. Any future telemetry must be opt-in, documented, and structurally incapable of carrying protected health information.
Note that including these building blocks does not make any deployment compliant. That is the whole distinction this page exists to draw.
No real patient data may ever appear in this repository or its surrounding spaces. Not in issues, pull requests, commit messages, code, tests, fixtures, seed data, screenshots, or logs.
Use obviously synthetic data. Generated synthetic records, or invented identities that could not be mistaken for real people: "Testina Patientsson", MRN OR-100482, "Dr. Okafor", "Placeholder Mutual Health". Identifiers should come from reserved or non-routable ranges. The database seed follows all of this and is a good reference for what acceptable fixture data looks like.
Anything containing real data is scrubbed or deleted on sight and treated as a data incident.
Two consequences worth understanding.
The rule cannot be automated away. ADR-0004 considered and rejected using a model to detect patient-shaped data in the repository, on the grounds that correct synthetic data is deliberately shaped like real patient data, so precision approaches zero and the gate would be muted within a week. Enforcing the rule is a provenance problem, not a detection problem.
The rule shapes what gets logged. Deterministic redaction cannot catch a name inside a free-text sentence in an exception payload, so the mitigation is not to log free text in the first place.
openrunic ships no terminology content, and this is a deliberate differentiator.
SNOMED CT content is licence-restricted and must never be vendored into this repository. LOINC, ICD-10-CM, and RxNorm have friendlier licensing but still ship as deployment-time content, not repository content.
The schema is built for this. Any code from a licensed or evolving terminology is a plain string plus a codeSystem string, never a database enum. TerminologyCode is a bring-your-own cache whose system column is a string rather than an enum, specifically so a new system can be loaded without a migration. Each deployment loads only what it is licensed for.
Terminology support will be a pluggable service interface rather than bundled content.
The same reasoning extends to model weights. ADR-0004 notes that several widely published domain-adapted biomedical models are trained on corpora whose licence forbids redistribution and are then published permissively with no documented chain of title. That is structurally the same problem as vendoring terminology, and the project takes the same position on both.
FHIR R4 (4.0.1) exclusively. The implementation guides that carry regulatory weight in both the US and the EU are R4-based. R4B and R5 have no regulatory driver. The next jump is R6, expected around 2027, and because resource handling sits behind the mapping layer that would be a mapper change rather than a rewrite.
Authentication: plain OIDC first, SMART on FHIR later. First-party applications use OIDC with role-based access. SMART App Launch with granular scopes and SMART Backend Services come when third-party applications and bulk export arrive. The data-access layer is designed to enforce scope-to-filter rules from the start so that layering is additive rather than a rewrite.
Two regulatory tracks inform the architecture, and neither is a claim. In the US, certification criteria such as the standardised API criterion shape what the API surface should be able to do; pursuing certification is a possible future milestone, not a current status. In the EU, the European Health Data Space will impose interoperability requirements on EHR systems; it is tracked as a design input, and openrunic makes no conformance claim.
AGPL-3.0-only. If you run a modified version of openrunic as a network service, the licence requires you to offer the source of your modified version to its users.
The dependency licence policy follows from this. .grant.yaml is deny-by-default and allows only the project's own licence family plus the permissive AGPL-compatible set, with each addition carrying its compatibility rationale. See Security and supply chain.
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.