Roadmap

Roadmap

This page describes direction, not dates. It covers only what the repository already commits to in public: what the README says is being built first, what the ADRs and configuration files record as follow-ups, and what is in flight on a branch. It is for anyone deciding whether to depend on something or to pick up work.

Nothing here is a promise. openrunic is pre-alpha, there are no releases, and priorities can change. Where a page in this wiki says something is not implemented, that is the accurate present tense.

What is being built first

From the README, the first product is a modern, fast, lightweight EMR:

• Patient demographics and registration
• Scheduling and appointment management
• Clinical encounters and documentation
• A FHIR R4 API at the service boundary, so integrations speak an open standard from day one
• Audit logging as a first-class feature rather than an afterthought

The data model already covers considerably more than that list, including orders, results, and the full revenue cycle. The list above is what the project has said it is finishing first.

In flight

Each of these is real work on a real branch, and none of it is merged.

Workstream	Branch	State
Staff EMR application, 26 routes	feat/emr-app	Substantially built in mock mode. See Web app.
Patient portal	feat/patient-portal	Shell, six routes, and a data layer. See Patient portal.
API route expansion	feat/api-routes	Early. Seven aggregates are reserved and answer 501 today.
@openrunic/x12	feat/emr-packages	A codec for the electronic claim, remittance, acknowledgement, and eligibility transaction sets. Reader, writer, segments, control, and delimiter handling exist.
@openrunic/forms-engine	feat/emr-packages	Scaffolded. The runtime for compiling, validating, rendering, printing, and promoting forms. See Form engine.
@openrunic/terminology	feat/emr-packages	Scaffolded. Bring-your-own terminology services. Ships no licensed content.
@openrunic/adapters	feat/emr-packages	Scaffolded. Versioned partner-adapter contracts, deterministic mocks, and a capability registry.
Self-host packaging	feat/ops-selfhost	An API image with runtime and migrate targets, plus a boot-time schema step. See Self-hosting.

Recorded follow-ups

These are written into the repository as explicit next steps, each in the file that owns the decision.

Enable Postgres row-level security. The policy is written out in the schema header. It is deferred until the API wraps each request in a transaction that sets the tenant session variable, because enabling it first would lock the application out of its own database. See Multi-tenancy and isolation.

Turn on the Sonar stage. Blocked on creating the projects and adding tokens, not on code. The DISABLE_SONAR variable is a kill switch, and removing it is the last step rather than the first.

Promote Supply Chain Required to a required check. ci.yaml's aggregate is required today; the supply-chain workflow has its own aggregate built on the same fail-closed pattern, and making it required is described as a deliberate follow-up once it has a track record.

Harden the licence gate. .grant.yaml sets require-license: false so packages with no machine-readable licence field fail on a real conflict rather than on missing metadata. Flipping it to true is the documented follow-up once that tail is triaged.

Move the web production build into the shared build job and upload its output as an artifact, once a hosting target exists. The comment in _core.yaml even records the flag that upload will need.

Raise the coverage floors. The floors on dev are lower than the bar the project is working to. See Testing strategy.

Add a scheduled type-aware analysis as a backstop if the Sonar scan-only design starts to miss rules that need type resolution.

Pin the CI Postgres major to production's once a production database exists. Migration SQL proven against a newer server than production is not proof.

Direction, from the ADRs and the compliance posture

Stated as design intent in the repository, without a schedule attached.

Interoperability. FHIR R4 exclusively. The next regulatory jump is R6, tracked as a future mapper change rather than a rewrite. The FHIR search surface starts deliberately small and grows parameter by parameter against relational columns, because that is the accepted cost of relational storage.

Authentication. Plain OIDC with role-based access for first-party applications first. SMART App Launch with granular scopes and SMART Backend Services when third-party applications and bulk export arrive. The data-access layer is designed so that layering is additive.

Terminology. A pluggable service interface. No licensed code content in the repository, ever.

Machine learning. Not in the core deployment. If it ever ships it is an optional, out-of-process adapter behind the existing partner-adapter seam, never on the request path and never required for the product to run. Five rules would bind such an adapter: never auto-commit to the chart, always display the source span, never rank by clinical risk, never emit content absent from the source, and state the intended purpose as documentation support. See ADR-0004.

Branch model. Trunk-based development is explicitly a "revisit once releases and release branches exist" question, not a closed one.

Releases. When they begin: semantic versioning, tags on main only, and component-scoped tags of the form web-vX.Y.Z and api-vX.Y.Z. Packages version with the application releases unless they are published independently later. See RELEASING.md.

Certification. Possible future milestones, not current status. See Compliance posture.

Explicit non-goals

Worth stating, because they are decisions rather than omissions.

• openrunic will not be a certified medical device, and makes no diagnostic claims.
• No terminology content will be vendored into the repository.
• No machine-learning runtime will live in the core deployment.
• There is no open-core model. AGPL-3.0-only, with no enterprise edition holding features back.

How to influence it

Open an issue with the feature template before writing significant code, so scope can be agreed first. If a change reverses or significantly extends a recorded decision, it needs an ADR in the same pull request. See Contributing guide.

Related pages

• Home for the current state table.
• ADR index for the decisions behind the direction.
• Compliance posture for what is and is not claimed.