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.
Where a new supplier of health data is signed up. A supplier might
be a clinic, a laboratory, or a company whose app or device records
measurements patients take at home.
Signing up happens on a short telephone call, with
a shared page open in front of both people — one at PDHC, one
at the supplier. Each fills in their own half. Neither can fill in
the other's, and nothing counts as agreed until both have confirmed
it, so the record is of what the two of them actually decided
rather than what one of them assumed.
Together they settle which measurements will be sent, who is asking
for them, and how the data will travel. The list of measurements
comes from a care plan that already exists, so what is promised
cannot drift from what the care actually requires.
It takes about twenty minutes and ends with two things: a written
agreement, and a key that lets the supplier's system connect. The
key is shown once, on the supplier's own screen — nobody at
PDHC ever sees it.
Starting one needs a PDHC administrator account
— you will be asked to sign in. The supplier needs no account
at all; they get a link and a spoken code.
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.
Individual, point-of-care clinical decision assist (the former Dashboard, refocused — the care-delivery half of the analyse-engine split #533). Single-patient views — charts on the patient's CDR record plus the nurse summary / AGP / per-variable trend / events. Gated on a care relationship (care-delivery, not the analysis phase), with per-patient spärr. The group / population engine now lives in analyse.
Group / population analysis — the group half of the analyse-engine
split (#533); the individual point-of-care half is cd-assist.
Researcher / cohort builder plus the federated observation-search,
stats, canonical-table and openEHR endpoints, fanned out across
CDR2–6. Analysis-phase gated (SSO + analysis membership);
the gateway analyse-pull routes here. Cohort reads pass ips.pdhc's
consent filter and per-clinic spärr, both fail-closed.
Built, awaiting deployment: a rebuilt federated
analysis engine (#644–#661, #684). An analyst writes a
spec — a question — which is signed and fanned
out to one node per CDR; each node computes sufficient statistics
over its own rows and returns only aggregates, and the coordinator
merges them. No patient identifier crosses between them, and
disclosure control is applied again over the merged figures under
the strictest contributing policy. A source that did not answer is
always named, so a pooled figure is never silently about a smaller
population than was asked for. Live today is the pre-reconstruction
build (0.2.0-reform).
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.