Skip to main content

Using Gravity Rail with PHI

Do not send Protected Health Information (PHI) to Gravity Rail unless your organization has an Enterprise account and a fully executed Business Associate Agreement (BAA) with Gravity Rail, and Gravity Rail has explicitly approved the intended organization, each workspace, and the services that will handle PHI. Wait for our confirmation before sending PHI. A field label, workspace feature, or signed BAA by itself is not that approval.

Contact support@gravityrail.com before using Gravity Rail with PHI. Include the organization and workspace UUIDs, but do not include patient information in the request.

Required Approval Boundary​

Authorization to use Gravity Rail with PHI depends on both contractual coverage and confirmed service configuration. Neither workspace feature flags nor an agent's response can establish that authorization.

Until Gravity Rail confirms PHI authorization for the intended scope:

  • use synthetic or non-PHI data only
  • do not infer authorization from another workspace in the same organization
  • do not infer authorization from a healthcare product name or integration
  • do not ask an AI agent to determine whether the service is HIPAA compliant

Classify Form fields that contain PHI​

Field labels describe the data in a Form. They help Gravity Rail classify the Form and its records; they do not approve PHI use, change who has access, or replace your BAA. Category describes the content type. Sensitivity is its disclosure level.

For each field that stores PHI:

  1. Open the Form's Details page and expand the field you want to classify.
  2. Open More settings.
  3. Under Categories, select PHI. Under Sensitivity, select Restricted or a stricter level if the field warrants it. PHI requires at least Restricted sensitivity; the editor raises a lower selection when you add the PHI category.
  4. Use a Member-scoped Form for member-specific records. A Workspace- scoped Form cannot use the PHI or Credential categories.
  5. Save the Form changes. If the Form already has a published schema, use Schema publications to save a draft, review the changes, and choose Publish schema. A saved draft does not change the live schema.

For API-created or updated Forms, include both fields on each PHI-bearing schema field object inside the request's fields array. For example:

{
  "slug": "care_plan_summary",
  "name": "Care plan summary",
  "fieldType": "longtext",
  "sensitivity": "restricted",
  "categories": ["phi"]
}

The Form API accepts sensitivity values public, internal, confidential, restricted, and secret; categories include personal, identifier, phi, and credential. Gravity Rail uses the PHI category to classify the Form for authorization checks; sensitivity records its disclosure level. These labels do not grant access or make PHI handling available in a workspace. Before entering PHI into any Form, first obtain the workspace and service approval described above.

Configure access before entering PHI​

After approval, review the intended Members' roles using Roles & Permissions. Check the Form's access settings with a synthetic record before entering patient information; field classification does not change those permissions.

Keep patient information in the approved records and messages. Use synthetic data in Workflow configuration examples, screenshots and support requests. If you add an integration or change the services handling PHI, contact Gravity Rail to confirm the revised scope before sending patient information through it.

Getting Help​

For BAA execution, PHI authorization, or questions about an existing configuration, contact support@gravityrail.com. Do not include PHI in the email.