Skip to main content

Clinical pathway ID filters on list queries

Summary

Nine Public API list queries now accept an optional clinicalPathwayId filter so integrations can fetch pathway-scoped objects directly, without loading a clinicalPathway and reading assignedObjects.

This complements ClinicalPathway.assignedObjects (pathway → objects). Filtering uses the same entity rules as assigned-object lists (for example non-deleted tasks, consultation grouping, lab status rules).

Only the child-entity permission for each query applies (for example seeBookings on bookings). seePathways is not required when filtering by clinicalPathwayId.

Malformed clinicalPathwayId values return a GraphQL validation error (BAD_USER_INPUT), consistent with clinicalPathway and episode ID arguments.

This change is additive: existing list queries behave as before when you omit the filter.

What changed

QueryFilter locationTypical permission
bookingsfilters.clinicalPathwayIdseeBookings
consultationsfilters.clinicalPathwayIdseeNotes
invoicesfilters.clinicalPathwayIdseeInvoices
labsoptions.clinicalPathwayIdseeLabs
lettersfilters.clinicalPathwayIdseeLetters
patientDocumentsfilters.clinicalPathwayIdseeDocuments
prescriptionsfilters.clinicalPathwayIdseeRx
tasksoptions.clinicalPathwayIdseeTasks
formsfilters.clinicalPathwayIdseeHospitalBookingForms

Example

query PathwayTasks($pathwayId: ID!) {
tasks(options: { clinicalPathwayId: $pathwayId }) {
data {
id
subject
patientId
}
pageInfo {
page
pageSize
hasMore
}
}
}

The same pattern applies to the other queries above: pass clinicalPathwayId in filters or options depending on the query.

Integration guidance

  • Prefer clinicalPathwayId on the list query that matches the object type you need instead of nesting under clinicalPathway when you do not need pathway metadata.
  • Combine with existing pagination and date/metadata filters where supported on each query.
  • seePathways is only required when you query clinicalPathway or clinicalPathways directly.

See also