Safety JSON Reference

Intake JSON Syntax

Section link for Intake JSON Syntax

Format JSON files properly to maximize the amount of data Safety can extract to import an Inbox Item from the Intake JSON endpoint.

The following list describes the basic structure of a Safety JSON intake file:

• data contains nested objects with data for a single case, such as case_contact__v.
• Objects can contain data within the structured array:
  • structured is an array containing key-value pairs of structured field data for a particular object.

Sample JSON File

Section link for Sample JSON File

Click the button below to download a sample JSON intake file with only structured data.

Download Sample JSON

Objects

Section link for Objects

Safety supports the following standard objects, which are nested under data for a single case:

• detail
  • The following child objects can be nested within detail under structured:
    • case_identifier__v
    • narrative
• patient
• case_product__v
  • The following child objects can be nested within case_product__v under structured:
    • case_product_dosage__v
    • case_product_indication__v
    • case_product_substance__v
    • case_assessment__v
      • The following child objects can be nested within case_assessment__v under structured:
        • case_assessment_result__v
• case_adverse_event__v
• case_contact__v
• case_cause_of_death__v
• case_medical_history__v
  • This object is also supported for Cases of Parental Information (parental_case__v) object type.
• case_drug_history__v
  • This object is also supported for Cases of Parental Information (parental_case__v) object type.
  • The following child objects can be nested within case_drug_history__v under structured:
    • case_drug_history_substance__v
• case_test_result__v
• case_relationship__v
• case_study_registration__v
• case_diagnosis__v
• transmission__v
  • The following child objects can be nested within transmission__v under structured:
    • destination__v
    • destination_transmission_id__v
    • first_sender__v
    • organization__v
    • origin__v
    • origin_transmission_id__v
    • reason_text_long_text__v
    • recipient_user__v
    • sender_person__v
    • sender_user__v
    • sender_comments__v
    • transmission_profile__v

For each object, Veeva Safety can map structured data from key-value pairs. Each JSON key must match a Vault field, which can be either a standard or custom field. For Date, DateTime, and Object type fields that have a corresponding Text version, map the data to the Text version of the field. For example, use the Text new_info_idate__v field instead of the Date new_info_date__v field when mapping data to the New Info Date field. Structured fields must be nested under the structured parameter and within the appropriate Safety object.

The following table outlines the supported field type formats that Safety can extract. In each object-type field, the value must exactly match the API Name for the Vault object record.

Field Type	Accepted Value
Reason Omitted	API Name of the Reason Omitted record, exactly as it appears in your Vault
Object (Controlled Vocabulary)	API Name of the Controlled Vocabulary record, exactly as it appears in your Vault
Object (Country)	2 or 3-character abbreviation or full country name, exactly as it appears in your Vault
Object (Unit of Measurement)	Name of the unit of measurement, exactly as it appears in your Vault
Object (Case Contact)	Name of the Case Contact object type, exactly as it appears in your Vault. The following types are supported: reporter__v, facility__v, or base__v
Object (Case Cause of Death)	Name of the Case Cause of Death object type, exactly as it appears in your Vault. The following types are supported: autopsy__v or reported__v
Date	Date in the following format: yyyy-MM-dd'T'HH:mm:ss.SSSXXX. For the New Info Date, the minimum level of precision required is the year, month, and day, yyyy-MM-dd. For example, 2012-02-26T03:45:12.123+03:30.
Number	Number value
Picklist	Comma-separated list of multi-value picklists, exactly as they appear in your Vault. For example, seriousness__v
Text	Characters in the text string
Yes/No	The boolean value (true or false)

Additional Fields (Pass-Through Fields)

Section link for Additional Fields (Pass-Through Fields)

The Intake JSON endpoint can ingest pass-through fields, which are fields that are present on the Case or Case-descendant objects but not on the Inbox Item object. This includes custom fields, which can be identified by an API Name ending in __c.

Pass through fields appear upon Case promotion. To be supported for pass-through, a field must be on one of the supported standard objects.

Consider the following requirements when formatting custom fields or pass-through fields for JSON intake:

• The key must exactly match the Vault field name, ending in __v for standard fields or __c for custom fields.
• The value format must comply with the Vault field properties and limits. An administrator can view these settings in the Vault Business Admin area.
• Number-unit pass-through fields must have both a valid number and a valid unit.
• The field must be nested within the appropriate object in the JSON file.
• For vaccine administration pass-through fields, consider the following:
  • To link a Case Product Dosage with the appropriate Facility-type Case Contact, match the administration_facility_id under a case_product_dosage__v with the facility_id under a case_contact__v with "object_type__v": "facility__v"
  • Do not add rank__v under a case_contact__v with "object_type__v": "facility__v"

Note

Standard Case patient fields must be nested within the patient object. Other (non-patient) Case fields can be nested in details. See the Pass-Through Fields Limits and Restrictions File for a list of Case patient fields. Custom Case fields are accepted under both patient and details, however the same field cannot be nested under both sections in the same file.

JSON Limits and Restrictions

Section link for JSON Limits and Restrictions

Veeva Safety imposes the following default limits on intake JSON files for each API call:

• A maximum of 15 custom JSON child objects. This limit does not include standard objects.
• A maximum of 500 records for each structured standard object and child object.
• A maximum of 100 structured data key-value pairs (fields) per structured standard object (record)
• A maximum of 20,000 characters of unstructured text per structured standard object (record), such as case_product__v
• A maximum JSON file size of 5MB

Pass-Through Field Limits and Restrictions

Section link for Pass-Through Field Limits and Restrictions

Certain fields are not supported. If data is received for unsupported fields, the system will ignore and not process that data. Click the button below to download a file listing the fields that are not supported for structured data intake.

Download Pass-Through Fields Limits and Restrictions