- Introduction
- 1. Why FerroEHR exists
- 2. Getting started
- 3. Installation
- 3.1. Try it in Codespaces
- 3.2. Docker Compose
- 3.3. Kubernetes & Helm
- 3.4. Cluster hardening
- 3.4.1. The cluster: hosts, control plane, access
- 3.4.2. Images: build, provenance, scanning
- 3.4.3. The workload: security context & admission
- 3.4.4. Namespaces, network & policy
- 3.4.5. Secrets, detection & response
- 3.5. From source
- 3.6. Configuration reference
- 3.6.1. Server, database & telemetry
- 3.6.2. Authentication & access
- 3.6.3. Integrations
- 3.6.4. Audit & subject proxy
- 3.6.5. Privacy & data minimisation
- 3.6.6. CLI & production checklist
- 4. Concepts
- 4.1. openEHR primer
- 4.2. System architecture
- 4.3. Storage architecture
- 4.4. The AQL engine
- 5. Using the API
- 5.1. Resource walkthroughs
- 5.2. Content negotiation & errors
- 6. Querying with AQL
- 7. Templates & validation
- 8. Beyond the core
- 8.1. EHR Extract & messaging
- 8.2. Demographics
- 8.3. Terminology servers
- 8.4. Subject Proxy
- 8.5. Change events (AMQP)
- 8.6. FHIR connectors
- 8.7. S3 multimedia
- 9. Security
- 9.1. Verifying releases
- 9.2. Threat model
- 9.3. Data protection impact assessment
- 9.4. Records of processing
- 9.5. Go-live checklist
- 9.6. Enterprise identity providers
- 9.7. SMART App Launch
- 9.8. Audit trail (IHE ATNA)
- 9.9. Version signing
- 9.9.1. Digest signing
- 9.9.2. PGP signing
- 10. FerroEHR Viewer
- 10.1. Dashboard & queries
- 10.2. Templates & EHR browsing
- 10.3. Demographics
- 10.4. Terminology
- 10.5. Operations panel
- 10.6. FHIR connector
- 10.7. Event subscriptions
- 10.8. Dark mode
- 11. Operations
- 11.1. Admin & messaging APIs
- 12. Conformance
- 13. Performance
- 14. Benchmarks
- 15. Comparison with EHRbase
- 16. Rust crates
- 17. Contributing
- 18. Licensing & legal
- 18.1. Compliance overview
- 18.2. Shared responsibility
- 18.3. Retention, restriction and objection
- 18.4. Control matrix
- 18.5. EHDS readiness
- 18.6. Technical documentation readiness