Reference source · 0.1.0-dev.11

project-roadmap.md

docs/project-roadmap.md · Download original file

# OPRP project summary and release roadmap

OPRP has a working experimental foundation. The immediate milestone is a public developer release: a Convey-branded documentation site at `oprp.convey.care`, versioned Git source, and usable TypeScript, Python and .NET SDKs. That release enables developers to build and test with synthetic records while the protocol continues toward an interoperable production baseline.

## What we have built

| Area | Working prototype behavior |
| --- | --- |
| Open addressing and hosting | Email-shaped patient addresses, WebFinger and signed domain-to-Host delegation; independently configured trust roots and patient-selected Hosts. |
| Protected exchange | Signed requests/responses with post-quantum payload encryption in both directions over HTTPS, requester/recipient binding and replay rejection. |
| Permissions and access duration | Host-issued scoped JWTs, explicit requested/approved periods, conditional patient approval, standing policies, emergency examples, bounded refresh and revocation. |
| Representatives | Separately authenticated parent/delegate actors, scoped authority, expiry and withdrawal checks; real evidence verification remains an integration. |
| Clinical operations | Declared Patient/lab subset plus six clinical types, separate read/create/update/delete scopes, immutable versions/history, attribution and conflict handling. |
| Outage recovery | Durable ordered queues, idempotent operation receipts, paged reads/change feeds and local mirrors in all three SDKs. |
| Visibility | Host-owned field/label filtering, incomplete representations, protected writes and cache-generation invalidation. |
| Notifications | Optional encrypted callback registration/challenge, durable hints/retries/deduplication and authorized polling for the actual records. |
| Portability | Signed export/import, independently encrypted backups, atomic restore and coordinated two-Host migration with custody fencing and discovery handoff. |
| Clinical validation | Six versioned R4 profiles, selected US Core targets, locked offline HL7 validation, finite local terminology and durable intake/migration jobs. |
| Developer operations | Injectable SQLite-compatible storage, identity-bound stores, private online snapshots, opaque health checks and a persistent two-Host lab. |

Detailed evidence lives in [implementation status](implementation-status.md), including unit/integration cases, real-engine validation, HTTPS demonstrations and packaged cross-language conformance. Documentation accompanies every implementation increment. No percentage-complete estimate is assigned: production readiness depends on evidence and resolved release gates, not only code volume.

## Public developer release

The public source should be a dedicated OPRP repository, containing only protocol software, schemas, documentation, SDK projects, synthetic tests and the documentation-site builder. The existing clinical portal and unrelated application configuration are separate. One repository can provide direct links to the three SDK projects and the reference Host while keeping one versioned specification and conformance suite.

The documentation site uses Convey's Cairo typography, violet/cyan palette and existing logo assets. All specification/guide sources are rendered into stable documentation routes. Developers should find the quickstart, installation packages, source links, compatibility limits, verification record and roadmap without needing a Convey account.

The publication checklist is:

1. Apache 2.0 is applied to OPRP original materials; preserve its license, attribution and third-party notices in every release.
2. Publish the dedicated repository to the approved GitHub account or organization.
3. Tag a verified developer version and attach SDK/profile installation artifacts and checksums.
4. Publish the full documentation site and verify its routes, assets, downloads and source links.
5. Connect `oprp.convey.care` using the actual DNS records returned by the hosting provider and verify HTTPS.
6. Add project contribution/security guidance and reproducible CI. Registry publication follows when maintainers are ready; a Git release can supply installable packages first.

## What remains after that release

| Priority | Work | Completion evidence |
| --- | --- | --- |
| Clinical breadth | Broader FHIR/US profiles, licensed LOINC/SNOMED CT/RxNorm/UCUM coverage, general Patient/Observation workflows, attachments and larger reads/transfers. | External validation and representative clinical workflows pass without silent data loss or unsupported-code acceptance. |
| Secure operations | Reviewed key custody, encrypted persistence adapters, deployable infrastructure, managed workers, monitoring, recovery/fencing and compromise handling. | Reproducible deployment, restart/restore/compromise exercises and tested custody protection. |
| Human authority integration | Actual enrollment, requester verification, patient decision delivery, representative evidence/custody/minor/POA policy and audit integration. | Hosts independently implement standing and interactive policies with the same protocol outcomes and current authority checks. |
| Independent interoperability | At least one independent Host/application and real provider integrations; broader vectors and negative/fuzz cases. | Independent implementations exchange records and recover from outages/migration using the published specification. |
| Governance and trust | Public issuance/trust admission rules, root/status distribution, policy profiles, conformance/assessment distinction and compatible versioning. | Third parties can operate without Convey's exclusive approval or runtime directory. |
| Security assessment | Independent cryptographic/protocol/application review; forward-secrecy and streaming design resolved or explicitly bounded. | Material findings resolved and security claims supported by review evidence. |
| Stable protocol | Freeze interoperable scope and versioning after those gates. | Required conformance cases pass with clear compatibility and release policy. |
| Convey EMR | Build our EMR on the protocol's stable contracts. | Product workflows use the same published exchange/authorization/portability behavior as other vendors. |

Patient ownership and open governance remain central. Host policy still determines when a fresh patient decision is necessary, and storage providers remain responsible for their own at-rest protection. The protocol does not mandate a new Convey account, central DNS service, sole credential authority or repeated portal login.

**Next:** finish the public developer release, then expand clinical coverage and production operations in demonstrated increments while keeping documentation and SDK behavior aligned.