Skip to main content

PatientRelationshipType — new value SCHOOL

Summary​

The GraphQL enum PatientRelationshipType now includes SCHOOL.

You may see this value anywhere the API returns relationshipType on patient relationships (for example PatientRelationship) and on other types that reuse this enum (for example questionnaire-related fields).

This is normal API evolution: existing queries and mutations continue to work as before. We recommend that integrations handle new enum values gracefully over time so additions do not cause deserialization or mapping failures.

Integration guidance​

Treat relationshipType as an open set. We may add further enum members as the product grows. Resilient integrations should:

  • Parsing: Accept any string the API returns for this field. Avoid response parsers that reject values not present in an older client build.
  • UI and business logic: Map values you depend on explicitly (including SCHOOL where it matters), and use a safe fallback (for example a generic “Relationship” label) for anything else—including future enum values.
  • Codegen and strict enums: Refresh the schema, regenerate clients, and add SCHOOL where you maintain typed enums. Where your language allows, prefer a default or catch‑all branch so unknown values do not crash at runtime.

Mutations​

Where mutations accept relationshipType, you may send SCHOOL when it matches your use case. All previously valid values are unchanged.

If something breaks after this change​

Problems usually come from strict client-side handling (unknown enum value, deserialization errors, or non‑exhaustive switch / match). The GraphQL shape of your operations has not changed.

Check: update your schema snapshot, regenerate types, extend local enums and display maps, and relax response parsing so unexpected enum strings are handled (log and fallback) instead of throwing.

See also​