As an admin, I can create and manage Practitioner and Patient resources

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

charles/koinos#11

claude-desktop commented

2026-04-14 20:41:43 +00:00

Collaborator

User story

As an admin, I want to create, read, update, and deactivate Practitioner and Patient resources through the Koinos backend, so that clinical workflows have the core subjects they need.

Acceptance criteria

Endpoints (proxied to HAPI FHIR with policy enforcement)

POST /api/practitioners — admin only.
GET /api/practitioners/{id} — any authenticated user.
PATCH /api/practitioners/{id} — admin or the practitioner themselves.
DELETE /api/practitioners/{id} — admin only (soft delete via active=false).
POST /api/patients — admin or practitioner with care relationship.
GET /api/patients/{id} — policy-checked (practitioner with active care relationship, the patient themselves, admin).
PATCH /api/patients/{id} — same policy as GET.
Search: GET /api/practitioners?family=...&given=... and GET /api/patients?....

Validation

Every write validated against the loaded FHIR profiles.
Clear error responses using FHIR OperationOutcome.

Backend internals

FHIR client module in koinos-core wrapping HAPI FHIR calls.
Policy layer consulted before every read/write.
AuditEvent recorded for every write (read auditing wired in #20).

Tests

Integration tests covering CRUD and authorization paths.
Property-style test verifying search pagination.

Out of scope

Cross-instance patient lookup (later).
INS qualification (v0.2).
RelatedPerson and CareTeam CRUD (v0.2).

References

spec/03-architecture/04-medical-data.md.
spec/04-functional/03-patient-record.md.
spec/08-roadmap-mvp.md — step #11.

## User story **As an admin**, I want to create, read, update, and deactivate `Practitioner` and `Patient` resources through the Koinos backend, **so that** clinical workflows have the core subjects they need. ## Acceptance criteria ### Endpoints (proxied to HAPI FHIR with policy enforcement) - [ ] `POST /api/practitioners` — admin only. - [ ] `GET /api/practitioners/{id}` — any authenticated user. - [ ] `PATCH /api/practitioners/{id}` — admin or the practitioner themselves. - [ ] `DELETE /api/practitioners/{id}` — admin only (soft delete via `active=false`). - [ ] `POST /api/patients` — admin or practitioner with care relationship. - [ ] `GET /api/patients/{id}` — policy-checked (practitioner with active care relationship, the patient themselves, admin). - [ ] `PATCH /api/patients/{id}` — same policy as GET. - [ ] Search: `GET /api/practitioners?family=...&given=...` and `GET /api/patients?...`. ### Validation - [ ] Every write validated against the loaded FHIR profiles. - [ ] Clear error responses using FHIR `OperationOutcome`. ### Backend internals - [ ] FHIR client module in `koinos-core` wrapping HAPI FHIR calls. - [ ] Policy layer consulted before every read/write. - [ ] `AuditEvent` recorded for every write (read auditing wired in #20). ### Tests - [ ] Integration tests covering CRUD and authorization paths. - [ ] Property-style test verifying search pagination. ## Out of scope - Cross-instance patient lookup (later). - INS qualification (v0.2). - `RelatedPerson` and `CareTeam` CRUD (v0.2). ## References - `spec/03-architecture/04-medical-data.md`. - `spec/04-functional/03-patient-record.md`. - `spec/08-roadmap-mvp.md` — step #11.

claude-desktop added this to the v0.1 milestone

claude-desktop added the

area:clinical

area:backend

type:user-story

labels

Rows
Columns

As an admin, I can create and manage Practitioner and Patient resources #11