GraphQL queries and pagination

The checked sandbox schema exposes three query fields for each of its 162 FHIR and Ovok platform types:

Query shape	Example	Purpose
Read by ID	Patient(id: ID!)	Fetch one resource by its logical ID.
List	PatientList(...)	Return matching resources as a list.
Connection	PatientConnection(...)	Return matches with count, cursor strings, and edges.

The exact resource fields and search arguments vary by resource. The FHIR resource catalogs list the root fields and search arguments introspected from the sandbox. The linked FHIR resource page explains resource elements and standard search parameters.

Read one resource

A single-resource query takes a required GraphQL ID. Select only the fields the caller needs:

query ReadPatient($id: ID!) {
  Patient(id: $id) {
    id
    active
    name { family given }
  }
}

Send variables separately from the operation text:

{
  "query": "query ReadPatient($id: ID!) { Patient(id: $id) { id active name { family given } } }",
  "variables": { "id": "<patient-id>" }
}

This is a request example, not a real patient response. The token must be authorized to read the Patient.

Search a list

The sandbox declares the following common arguments on resource list fields:

Argument	GraphQL type
_count	Int
_offset	Int
_sort	String
_id	String
_lastUpdated	String
_filter	String
_cursor	String
_compartment	String
_profile	String
_security	String
_source	String
_tag	String

Each resource adds its own search arguments. In the inspected schema those arguments are String; use their exact GraphQL names from the catalogs. These names do not expand FHIR search: they are the endpoint declared arguments, while supported search semantics come from FHIR and project capabilities. See FHIR basics, the FHIR resource reference, and the CapabilityStatement route.

query FindPatients($count: Int, $family: String) {
  PatientList(_count: $count, family: $family) {
    id
    name { family given }
  }
}

{
  "query": "query FindPatients($count: Int, $family: String) { PatientList(_count: $count, family: $family) { id name { family given } } }",
  "variables": { "count": 10, "family": "Example" }
}

The example demonstrates query syntax only; it does not imply that the project contains matching data.

Use a connection result

The sandbox PatientConnection result has count, offset, pageSize, first, previous, next, last, and edges. Each edge has mode, score, and resource; this schema uses resource, not Relay's node field.

query PatientPage($count: Int, $cursor: String) {
  PatientConnection(_count: $count, _cursor: $cursor) {
    count
    offset
    pageSize
    first
    previous
    next
    last
    edges { resource { id name { family given } } }
  }
}

The schema accepts _cursor and returns cursor strings. It does not define a Relay pageInfo object. Use a cursor returned by the same environment as-is; do not manufacture cursor values or assume semantics from another GraphQL server.

Handle the response

A GraphQL response can contain both data and errors. Inspect errors even when HTTP is successful, and avoid logging personal or clinical fields that are not needed:

{
  "data": {
    "PatientList": [{ "id": "<patient-id>" }]
  }
}

This response shape is illustrative. For standard FHIR search, REST interactions, and operations such as $populate, $extract, and $lastn, use Ovok primitives.