Skip to main content

Clinical pathway assigned objects

Summary​

The ClinicalPathway type now exposes assignedObjects, a nested object that returns linked records assigned to a pathway (appointments, tasks, invoices, and other pathway-linked types) in a single GraphQL query.

Use it on clinicalPathway or clinicalPathways when your integration already has access to clinical pathways ( seePathways permission and the EPISODES_OF_CARE feature segment).

This change is additive: existing pathway queries behave as before. Omit assignedObjects from your selection set if you do not need linked objects.

What changed​

New field on ClinicalPathway:

  • assignedObjects: ClinicalPathwayAssignedObjects! — non-null container; each sub-field is a list (empty when nothing is assigned).

New type ClinicalPathwayAssignedObjects:

Sub-fieldTypeTypical permission
appointments[Booking!]!seeBookings
tasks[Task!]!seeTasks
invoices[Invoice!]!seeInvoices
documents[PatientDocument!]!seeDocuments
consultations[PathwayConsultationSummary!]!seeNotes
letters[Letter!]!seeLetters
forms[HospitalBookingFormData!]!seeHospitalBookingForms
prescriptions[Prescription!]!seeRx
labs[Lab!]!seeLabs

Most sub-fields use the same public GraphQL object types as elsewhere in the API. consultations returns PathwayConsultationSummary rows (a slim list shape: id, patient, date, encounterType, doctorName, questionnaireId, deleted) rather than the full Consultation type. Filtering and grouping match internal pathway behaviour (for example non-deleted tasks and letters, invoice type rules, lab status rules, and consultation grouping via records).

Example query:

query ClinicalPathwayWithAssignments($pathwayId: ID!) {
  clinicalPathway(id: $pathwayId) {
    id
    assignedObjects {
      tasks {
        id
        subject
        patientId
      }
      invoices {
        id
        patientId
      }
      consultations {
        id
        encounterType
      }
    }
  }
}

Batching across pathways:

query ClinicalPathwaysWithTasks($episodeId: ID!) {
  clinicalPathways(episodeId: $episodeId) {
    id
    assignedObjects {
      tasks {
        id
        subject
      }
    }
  }
}

Integration guidance​

  • Request only the sub-fields you need. Omitted sub-fields are not loaded; there is no work for types you do not select (for example, do not request labs if you only need tasks and invoices).
  • Empty assignments return [], not null, for each list sub-field you request.
  • Permissions apply per sub-field. Your API token must have the relevant role permission for each type you query under assignedObjects. If a sub-field is not permitted, it is not returned as part of the resolved selection.
  • No pagination on assignedObjects yet. Lists return all assigned objects for the pathway for each requested type. Plan follow-up work if you expect very large assignment sets.
  • Episodes of care: Pathway queries require the EPISODES_OF_CARE segment. Practices without it cannot use clinicalPathway, clinicalPathways, or assignedObjects.

Example response​

{
  "data": {
    "clinicalPathway": {
      "id": "507f1f77bcf86cd799439011",
      "assignedObjects": {
        "tasks": [
          {
            "id": "507f191e810c19729de860ea",
            "subject": "Follow-up review",
            "patientId": "507f1f77bcf86cd799439012"
          }
        ],
        "invoices": [],
        "consultations": [
          {
            "id": "consultation-abc123",
            "encounterType": "Visit"
          }
        ]
      }
    }
  }
}