Changelog

v1.2.1

Released date: 2026-08-03

Motivation

Improve data quality and prevent leaking real national identity numbers (NIN) through the test & dev environment

Changes

We only accept synthetic NINs in the dev & test environment, and we will only accept real NINs in production

v1.2.0

Released date: 2026-07-28

Motivation

Providers need to independently control when a plan is visible to patients in their own systems. The publication workflow enables per-provider publication tracking.

Changes

• Added POST /api/v2/plan/{id}/$publish to mark plan as published for the requesting provider
• Added POST /api/v2/plan/{id}/$unpublish to mark plan as unpublished for the requesting provider
• Publish and unpublish commands require version and content_version to specify which content snapshot to publish
• PlanResponse now includes content_version (independent content version counter)
• PlanResponse now includes publication_status (array of PublicationEntry per provider)
• HistoryResponse now includes content_version, approval_status, and publications (count of publication entries)
• PublicationEntry model: provider_id, status (published/unpublished), content_version, published_at

v1.1.1

Released date: 2026-07-20

Motivation

Improve routing internally in NHN

Changes

All endpoints exposed to clients are prefixed /api/. This means that GET /v2/plan/{id} becomes GET /api/v2/plan/{id} and so on

v1.1.0

Released date: 2026-07-01

Motivation

The CQRS pattern (/write/ and /read/ prefixes) is an internal implementation detail that shouldn't be exposed to API consumers. Additionally, automatic API documentation via Swagger improves developer experience.

Changes

• All v2 endpoints unified under /v2/ prefix, hiding the internal /write/ and /read/ CQRS separation
• GET /write/plan/{id} renamed to GET /v2/plan/{id}/$latest
• Swagger UI available at /swagger/
• 409 Conflict responses include Location header pointing to the plan's $latest endpoint

v1.0.0

Released date: 2026-06-30

Motivation

The API has been rewritten with CQRS to separate mutations from queries and added an approval workflow for plan governance.

Changes

• All mutations moved under /write/plan, all queries under /read/plan
• Single PUT /plan/{id} replaced with dedicated endpoints: $update-content, $draft, $activate, $revoke
• New approval workflow: $approval-requested, $approval-given, $approval-rejected
• Read response includes approval_status, rejection_reason, revoke_reason fields
• Search endpoint supports approval_status query parameter (pending, approved, rejected)
• Mutation endpoints return minimal response ({id, version}); use GET to retrieve full plan
• Added GET /write/plan/{id} for reading from the write model
• Documentation moved to Endpoints_v2.md

v0.4.0

Released date: 2026-06-15

Motivation

Clients need to retrieve a specific historical version of a plan, not just the latest one. This complements the History endpoint (which returns metadata only) by returning the full plan object at a given version.

Changes

• Added GET /plan/{id}/version/{version} endpoint returning full Response object
• Returns 400 for invalid UUID or version format, 404 for plan or version not found

v0.3.0

Released date: 2026-06-12

Motivation

The API now supports retrieving the full version history of a plan, enabling audit trail use cases. Additionally, the Search endpoint now requires the patient parameter to prevent unintended broad queries.

Changes

• Added GET /plan/{id}/history endpoint returning []HistoryResponse
• Added HistoryResponse model with fields: version, status, updated_at, updated_by, comment
• patient query parameter is now mandatory in Search endpoint (returns 400 when missing)

v0.2.0

Released date: 2026-06-12

Motivation

The API model has been refactored to separate request and response. This provides a cleaner public API where server-assigned fields (id, version, updated_at) are not exposed in request bodies, and consumers receive dedicated response objects.

Additionally, the API now enforces optimistic locking via version checking on updates.

Changes

• Split single Request model into CreateRequest, UpdateRequest, and Response
• Renamed plan field to clinical_content in all requests and responses
• Renamed Plan model to Content / Clinical Content
• CreateRequest no longer accepts version — assigned by server
• UpdateRequest requires version — must match current server version for optimistic locking
• Update endpoint returns 409 Conflict on version mismatch, 422 Unprocessable Entity on missing version
• Updated active status description to clarify it does NOT imply the plan is approved

v0.1.0

Released date: 2026-06-12

Motivation

Based of the feedback from work meeting 2026-06-11, we have revised which FHIR statuses to include as of now.

Furthermore, we have updated the documentation for the active status to not imply the plan is approved. This does not currently cause any behavioural changes in the API.

Changes

• Added Request.status option revoked
• Removed Request.status options completed and on-hold