You can visualize and explore the TELUS Collaborative Health Record (CHR)’s Enterprise API’s schema in a GraphQL Voyager. This is useful to learn about our API before you have access to the API from your CHR account.
GraphQL supports self discovery via an introspection query. The Insomnia and Postman tools support GraphQL schemas in various ways. Refer to your selected tool’s documentation for information about how to best import/consume the GraphQL schema.
The CHR Enterprise API, as a GraphQL API, consists of Queries and Mutations. Queries support the fetching of data and Mutations support the creation/update of data.
Root queries are named after the data available through them, such as appointment (to fetch a single appointment) and appointments (to fetch a list of appointments).
Mutations are named depending on what data they operate on, such as createAppointment (to add a new appointment).
The CHR Enterprise API is designed to support the real time fetching and updating of data as needed and is not optimized for the regular synchronization of data between systems.
For information on how to navigate the CHR Enterprise API schema, refer to Navigating the CHR Enterprise API schema (GraphQL Voyager).
Query ordering
The API orders responses in the following way based on the object being queried:
Patients: By ID
Appointments: By date
Query filtering
The API supports filtering results based on one or more fields. Filters are only required when indicated by the schema. If you use multiple filters, they are applied together to narrow the results.
Query pagination
The API adheres to the GraphQL Cursor Connections Specification (https://relay.dev/graphql/connections.htm) for objects that warrant pagination (such as appointments and patients). Simple objects (such as locations and serviceTypes) are returned as an array of records. Page sizes default to 50 with a maximum page size of 100.
Mutations
The API supports the creation of objects via mutations. These follow argument patterns, providing one or both of these:
Input argument: contains data that should be set to database model
Options argument: contains data to indicate how the CHR should process that object (such as indicating that an appointment requires confirmation)
Business logic that is defined within your CHR account is enforced via the API. For example, an appointment type’s defined minimum or maximum booking times or a provider’s defined working hours/location are enforced.
Updated February 1, 2022