Microservice platform for healthcare coordination — built on FHIR R5
Authentication and authorisation service. Issues JWT tokens, manages user identities (patients, professionals, superusers), and handles organisation and group memberships. Implements OAuth 2.0 with PKCE and exposes OIDC-compliant endpoints.
Care plan definition builder. Define reusable PlanDefinition templates composed of medical concepts, value sets, goals, and activities. Web-based builder with live FHIR JSON preview and SNOMED CT / LOINC terminology support.
SNOMED CT / LOINC terminology service. Powers concept lookups, $expand / $validate-code / $translate operations consumed by plan.pdhc and downstream services. Not exposed via the public reverse proxy — sibling services reach it through the docker network (TERMBANK_BASE_URL).
Patient records and care plan execution. Manages FHIR Patient resources, provides care plan readout with filtering and CSV export, and dispatches care plans to providers with receipt tracking.
International Patient Summaries. Generates standardised FHIR bundles compiling conditions, observations, medications, allergies, immunisations, and procedures into portable documents with delivery tracking.
Healthcare contracts between payers and providers. FHIR R5-compliant contract resources with version tracking, search and filter capabilities, and a web-based administration interface.
Care provider portal. Providers authenticate via API key, receive dispatched tasks, acknowledge receipt, and submit structured completion reports. Enforces idempotency with an immutable receipt trail.
Patient questionnaire assignment service. Receives dispatched ServiceRequests from request.pdhc.se via webhook, creates assignments per patient, and stores FHIR QuestionnaireResponse resources for completion tracking.
Continuous glucose monitoring provider. Receives procedure-based ServiceRequests, auto-starts a background glucose stream on task acknowledgement, and delivers continuous observation batches to the gateway until manually stopped.
Provider data ingestion gateway. Validates Provider Access Tokens issued by request.pdhc, receives FHIR Observation and QuestionnaireResponse reports from providers, enforces HMAC-signed composite key grants, and maintains a full audit trail.
Read-only analysis dashboard. Lists eligible patients within the user's organisation, shows latest values and time-activity curves per concept, and exposes FHIR R5 Observation bundles. Belongs to the analysis phase — access requires SSO and analysis-phase membership.
Clinical data format translator. Converts patient observations from gateway.pdhc into three standards: FHIR R5 (with full metadata back-references to ServiceRequest, PlanDefinition, Contract, and Organizations), openEHR Compositions, and OMOP CDM measurements. Exposes a FHIR CapabilityStatement and per-patient JSON APIs. Belongs to the analysis phase — access requires SSO and analysis-phase membership.
Canonical clinical data repository. Three-layer storage (raw, FHIR R5 + openEHR dual-standard, canonical flat tables) with bidirectional FHIR↔openEHR transformation, LOINC-to-archetype mapping, and automatic delivery to the Cambio CDR sandbox. Sole source-of-truth for gateway-forwarded observations (SSOT cutover #285). Belongs to the analysis phase — access requires SSO and analysis-phase membership.
Sim-populated demo CDR — same three-layer storage as CDR1, seeded with synthetic longitudinal patient data (~100 patients, ~2.6M observations) for federation and analyse development. Read-only from the analyse layer; CDR_READ_LOCKDOWN=true.
Sim-populated demo CDR — same three-layer storage as CDR1, seeded with synthetic longitudinal patient data (~100 patients, ~2.6M observations) for federation and analyse development. Read-only from the analyse layer; CDR_READ_LOCKDOWN=true.
Sim-populated demo CDR — same three-layer storage as CDR1, seeded with synthetic longitudinal patient data (~100 patients, ~2.6M observations) for federation and analyse development. Read-only from the analyse layer; CDR_READ_LOCKDOWN=true.
Sim-populated demo CDR — same three-layer storage as CDR1, seeded with synthetic longitudinal patient data (~100 patients, ~2.6M observations) for federation and analyse development. Read-only from the analyse layer; CDR_READ_LOCKDOWN=true.
The sim.pdhc synthetic-data sink. Same role as CDR1–5 in spirit — a landing store for cohorts — but a deliberately different, lightweight flat model (synthetic observations + read audit), not the Cambio-shaped FHIR CDR. Loopback-only: not on the public reverse proxy; sim reaches it over the docker network / an SSH tunnel. Holds the synthetic cohorts used for federation and analyse-layer development.
Synthetic-data generator. Produces reproducible, FHIR-coded
Swedish cohorts and pushes them into the platform — patients
into ips.pdhc, observations into a CDR (the CDR 6 sim sink).
generate-from-plandef drives MITRE Synthea straight
from a plan.pdhc PlanDefinition, so a cohort's observations are
exactly that plan's concepts, on its cadence, over a chosen time
window. All data is tagged synthetic; not exposed via the public
reverse proxy.