Skeleton Schema Registry (staging-81b54273)

ProviderApplication.provider_settings are used to store application-specific settings.

Event Metadata [Schema] [Examples]

Metadata for the event. Usually populated by the provider.

Event Reminders [Schema] [Examples]

Reminders for an event. This is synced post-save to Kronos and used as a convenient tool to trigger callbacks at a specific time before/after the event.

Clinic Program Monitoring Formset Parameter Mapping [Schema] [Examples]

ProviderApplication.provider_settings are used to store provider-specific settings such as API keys.

Chernobyl

MiniApp Settings [Schema] [Examples]

Chernobyl MiniApps define the schema of their source data and how the data should be displayed on the frontend.

Cleo

Clinic Calendar Metadata [Schema] [Examples]

Metadata of clinic calendar.

Clinic Calendar Parameter Mapping [Schema] [Examples]

Schema to describe how we extract values from caesar event to clinical parameters.

Clinic Calendar Settings [Schema] [Examples]

Settings for configuring clinic calendar.

Clinic Chart Settings [Schema] [Examples]

Schema for configuring the look and feel of a patient chart.

Clinic Group Settings [Schema] [Examples]

Settings for configuring miscellaneous clinic group settings.

Schema to describe how we extract values from clinic program monitoring forms to clinical parameters.

Clinic Program Parameter Mapping [Schema] [Examples]

Schema to describe how we extract values from clinic programs to clinical parameters.

Clinic Program Settings [Schema] [Examples]

Settings for configuring miscellaneous clinic program.

Clinic Settings [Schema] [Examples]

Settings for configuring miscellaneous clinic settings. This field is exposed to Frontend for Cleo users.

Clinic Table Settings [Schema] [Examples]

Schema for configuring the look and feel of a table.

ClinicRatatoskrProviderApplicationSettings Settings [Schema] [Examples]

Settings for configuring miscellaneous ClinicRatatoskrProviderApplication settings.

Clinical Parameter Settings [Schema] [Examples]

Settings for configuring miscellaneous monitoring formset and form settings. Note that the same settings are used for both monitoring formset and forms.

Clinical Parameter Value [Schema] [Examples]

Schema to describe how the clinical parameters values will look like.

Dialogue Settings [Schema] [Examples]

Schema for storing dialogue settings which include triger-responses.

DialogueTriggerResponse [Schema] [Examples]

The structure for dialogue triggers and responses.

Message Template Set User Variables [Schema] [Examples]

List of variables that a user can specify on the frontend for messaging patients.

Monitoring Formset Parameter Mapping [Schema] [Examples]

Schema to describe how we extract values from monitoring forms to clinical parameters.

Monitoring Formset/Form Settings [Schema] [Examples]

Settings for configuring miscellaneous monitoring formset and form settings. Note that the same settings are used for both monitoring formset and forms. For enrollment forms, the following QA fields are expected: - phone (required), - identifier (required), - monitoring_form (required), - names (optional), - language (optional), - communication_method (optional, default to SMS), - anything key ending with reminders (optional, this is also used for updating the form when global reminders are changed), - clinician_ics (array, optional, this is also used for updating the form when there are changes to clinicians), - clinician_alertees (array, optional, this is also used for updating the form when there are changes to clinicians)

Patient Event Metadata [Schema] [Examples]

Provides supplementary information about the patient event.

Patient Form Metadata [Schema] [Examples]

Settings for patient-form enrollment information.

Patient Program Metadata [Schema] [Examples]

Settings for patient-program enrollment information.

Cleo application specific permissions.

Profile Metadata [Schema] [Examples]

Provides supplementary information about the clinician.

Reminder Event Metadata [Schema] [Examples]

Schema to describe how the reminder event metadata will look like.

Reminder Schedule (DEPRECATED) [Schema] [Examples]

Schema for storing reminder schedules.

Reminder Settings [Schema] [Examples]

Schema for storing reminder settings which include schedules.

Role Permission [Schema] [Examples]

The list of permissions that are associated with a role. Note that mutate_* and query_* permissions are mutually exclusive; mutate implies query permissions.

Rule Parser Settings [Schema] [Examples]

Settings for configuring alert rule parsers.

Session Scopes (Cleo) [Schema] [Examples]

Cleo specific session scopes. A Cleo session can be scoped for either clinician or patient.

Shadowfax Event Properties (Cleo) [Schema] [Examples]

Cleo specific Shadowfax event properties.

Shadowfax User Properties (Cleo) [Schema] [Examples]

Cleo specific Shadowfax user properties.

Submission Comment [Schema] [Examples]

Content schema for submission comment.

Triggered Alert Metadata [Schema] [Examples]

Metadata for triggered alert such as the rule at time of trigger.

Einstein

Data Source [Schema] [Examples]

Settings for configuring an Einstein data source.

Document Entry File Metadata [Schema] [Examples]

Metadata specific to the data source.

Metric Snapshot Value [Schema] [Examples]

Schema for the value field of the MetricSnapshot model.

Module Settings [Schema] [Examples]

Settings for configuring an Einstein module.

Hospital application specific permissions. This is also known as ACL in Jarvis.

Profiles Group Ruleset [Schema] [Examples]

Define rules to return a subset of profiles. Used for broadcast groups, etc.

Profiles Group Ruleset Array [Schema] [Examples]

An array of ProfilesGroupRulesets.

Recurring Frequencies [Schema] [Examples]

An array of RecurringFrequency objects. This is used for any kronos task schedules.

Session Scopes (Einstein) [Schema] [Examples]

Einstein specific session scopes. See heimdall/SessionScopes.schema for more information.

Settings [Schema] [Examples]

Settings related to the einstein are stored in the respective Hospital.settings under the einstein field. This field will be exposed to the Frontend.

Shadowfax Event Properties [Schema] [Examples]

This is the schema for event properties in Einstein.

Shadowfax User Properties [Schema] [Examples]

This is the schema for user properties in Einstein.

Table Settings [Schema] [Examples]

Schema for configuring the look and feel of a table.

Eliza

Dialogue Trigger Entities [Schema] [Examples]

Array of entities that make up a trigger.

These settings are used for Eliza Providers in Chatterbox.

Response Content [Schema] [Examples]

This is the content encoded in the Response answer object for Jarvis data flow.

Faraday

Exam Metadata [Schema] [Examples]

Metadata for Parkway exam.

Facility Metadata [Schema] [Examples]

Metadata for Parkway facility.

Message Template User Variables [Schema] [Examples]

List of variables that a user can specify on the frontend for messaging patients.

Order Metadata [Schema] [Examples]

Metadata for order.

OrderExam Metadata [Schema] [Examples]

Metadata for OrderExam.

OrderExamLog Metadata [Schema] [Examples]

Metadata for OrderExamLog.

Parkway Staff Metadata [Schema] [Examples]

Metadata for Parkway Staff.

Patient Metadata [Schema] [Examples]

Metadata for patient.

Faraday application specific permissions.

Settings for Faraday facility provider.

Room Metadata [Schema] [Examples]

Metadata for Parkway room.

Session Scopes (Faraday) [Schema] [Examples]

Faraday specific session scopes. See heimdall/SessionScopes.schema for more information.

Staff Profile Request Metadata [Schema] [Examples]

Metadata for Staff Profile Request.

Fleming

Answer Content [Schema] [Examples]

These settings are used for Fleming Answers in Chatterbox.

These settings are used for Fleming Providers in Chatterbox.

Gideon

Keywords [Schema] [Examples]

Keywords/Regexes that should appear in the returned messages for gideon test queries.

Governess

Identifiable Information [Schema] [Examples]

A simple data structure to store identifiable information.

Growth

ProspectMetadata [Schema] [Examples]

Metadata for a prospect.

Heimdall

Application Input [Schema] [Examples]

Application inputs are used by Heimdall login frontends for application specific input values.

ProviderApplication.application_settings are used by backend to communicate with the authentication providers. This field will not be exposed to frontend.

Discovery Settings [Schema] [Examples]

Heimdall discovery is a simple pattern used by frontend to discover basic application settings from a universal endpoint based on simple URL rules. This is useful for retrieving settings such as GQL endpoints and language options.

Provider Input [Schema] [Examples]

Provider inputs are used by Heimdall login frontends for provider specific input values. These are usually things like access tokens and secret credentials generated by the authentication provider.

ProviderApplication.provider_settings are used by backend to communicate with the authentication providers. This field will not be exposed to frontend.

Provider-Application Settings [Schema] [Examples]

ProviderApplication.settings are usually settings required by frontend for handling authentication. As this will be provided to the frontend (sometimes without authentication), we should not store any secrets in here. Common fields stored here are ids, logos, color themes, etc.

Session Metadata [Schema] [Examples]

Session.Metadata are used to store session related metadata from provider/application.

Session Scopes [Schema] [Examples]

Session.scopes are used to limit what a user can/cannot do. Sessions can only use scopes from the same application.

Heisenberg

MonographSectionContent [Schema] [Examples]

This is the content encoded in the MonographSectionContent answer object for Jarvis data flow.

These settings are used for configuring the HeisenbergProvider in Jarvis.

Hospital

API Settings [Schema] [Examples]

Hospital.api_settings stores the credentials and information required to communicate with Hospital API (via the HospitalAPI class). This is not exposed to the frontend and is dependent on the hospital.

Common definitions [Schema]

A schema containing common properties required in Amplitude events.

Logic Settings [Schema] [Examples]

Hospital.logic_settings stores the information required for instantiating and customizing the HospitalLogic class. This field is not exposed to the frontend.

Hospital application specific permissions. This is also known as ACL in Jarvis.

Profile Settings [Schema] [Examples]

Profile.settings are used to store settings related to the users. This is often used as a NoSQL store by frontend. This is WIP.

Profile Tags [Schema] [Examples]

Profile tags are used to identify certain properties of users and control their access to data.

Session Scopes (Chemocalc) [Schema] [Examples]

Chemocalc specific session scopes.

Session Scopes (Hospital) [Schema] [Examples]

Hospital specific session scopes. See heimdall/SessionScopes.schema for more information.

Settings [Schema] [Examples]

Hospital.settings are used to store settings related to the hospital. This field will be exposed to the Frontend.

Shadowfax Event Properties [Schema] [Examples]

This is the schema for event properties in Hospital.

Shadowfax User Properties [Schema] [Examples]

This is the schema for user properties in Hospital.

Jarvis

Data Flow Event [Schema] [Examples]

This schema describes data events for Jarvis modules.

Engine Settings [Schema] [Examples]

These settings are used for configuring the chat Engine in Chatterbox.

Module Settings [Schema] [Examples]

These settings are used for configuring Jarvis chat Modules in Chatterbox.

Jarvis_tf

Test Suite [Schema] [Examples]

Test suite containing test cases and associated metadata.

Jarvisv2

Answer Syncer Settings [Schema] [Examples]

This contains all the settings needed for answer syncers.

Daily On Call Syncer Settings [Schema] [Examples]

Settings for syncing HMS Daily on Call rosters.

Einstein Directory Syncer Settings [Schema] [Examples]

This contains settings for syncing Einstein directorys.

Embedding Model Settings [Schema] [Examples]

Defines settings for the embedding model during data and query flow.

Grouped Answer Syncer Settings [Schema] [Examples]

GroupedSyncerSettings is a container for multiple Syncer settings. Syncers can be run concurrently via this object.

JarvisProfile [Schema] [Examples]

Profile for Jarvis V2.

LLM Model Settings [Schema] [Examples]

Defines settings for the LLM model during query flow.

Predefined Profiles [Schema] [Examples]

Predefined profiles for Jarvis. This can be used in Jarvis test framework as well as in the Jarvis CLI.

Query Engine Settings [Schema] [Examples]

This contains all the settings needed for the Jarvis v2 query engine.

TTSH JSON Web Directory Syncer Settings [Schema] [Examples]

This contains settings for syncing TTSH JSON directory Syncer Settings.

Tenant Resource [Schema] [Examples]

A resource file for defining tenant resources.

Kronos

Provider.settings are used to store task provider-specific settings.

Recurring Frequency [Schema] [Examples]

Recurring frequency objects describe complex recurring logic that are usually not supported by cron. This design is probably a super set of CRON.

Task Metadata [Schema] [Examples]

These are used to store task metadata. To separate between different task providers, we adopt a naming convention where the fields are named by the provider_key.

Maxwell

Maxwell application specific permissions.

Session Scopes (Maxwell) [Schema] [Examples]

Maxwell specific session scopes. See heimdall/SessionScopes.schema for more information.

Merlin

Session Scopes (Merlin) [Schema] [Examples]

Merlin specific session scopes.

Moneta

ProviderApplication.provider_settings are used to store provider-specific settings such as API keys.

Transaction Metadata [Schema] [Examples]

Transaction.metadata is used to store transaction metadata such as exception stacktrace.

Onform

ProviderApplication.application_settings are used to store application-specific settings such as API keys.

Form Settings [Schema] [Examples]

FormV2.settings is used to store form and provider information about FormV2s. Secrets are stored here.

ProviderApplication.provider_settings are used to store provider-specific settings such as API keys.

Question-Answer (QA) Parser Settings [Schema] [Examples]

QAParser.settings describes how fields can be parsed and extracted out of QAPairs. The basis of QAParser is QAField which describe individual normalized values that are extracted. During extraction, QAFields are iterated in a sequence for each QAPair to attempt extraction. As such, the order of precedence for non-array fields (i.e., is_array = false) are such that values extracted from later QAFields override earlier ones. For array QAFields (i.e., is_array = true), the extracted values are concatenated together.

Submission Metadata [Schema] [Examples]

SubmissionV2.metadata is used to store submission metadata such as processing status.

Ratatoskr

ProviderApplication.application_settings are used by ratatoskr.applications.AbstractApplicationss. This field is not exposed to frontend. This is where we store secret credentials.

Delivery Metadata [Schema] [Examples]

Delivery.metadata is usually set by providers to track the messages being sent and received.

Device Metadata [Schema] [Examples]

Device.metadata is common across providers and will be used by us for differentiating between types of devices.

Device Provider Metadata [Schema] [Examples]

Device.provider_metadata is used on Devices to store provider specific metadata about the device.

Message [Schema] [Examples]

This is the schema for messages as described and proposed in the Ratatoskr: Data Models for Messages RFC.

Message Provider Metadata [Schema] [Examples]

Message.provider_metadata is used on Messages to provide additional context to the provider for delivery.

Message Template [Schema] [Examples]

A convenience schema for representing a variety of message formats when editing via Mastermind.

ProviderApplication.provider_settings are used by ratatoskr.providers.AbstractProviders to communicate with the Provider API. This field is not exposed to frontend. This is where we store secret credentials.

Provider-Application Settings [Schema] [Examples]

ProviderApplication.settings are usually settings required by frontend. As this will be provided to the frontend (sometimes without authentication), we should not store any secrets in here. Common fields stored here are client_ids. For secret information, store it in provider_settings instead.

ReplyTo [Schema] [Examples]

This is the schema for the ReplyTo metadata representing replyee message information

WhatsApp Template Components [Schema] [Examples]

WhatsApp template components based on the documentation.

WhatsApp Template Metadata [Schema] [Examples]

WhatsApp template metadata

Rosters

Roster Provider Settings [Schema] [Examples]

Roster Provider Settings define the schema of their source data and how the data should be displayed on the frontend.

Scalpel

Filter Settings [Schema] [Examples]

Schema for storing filter settings.

TabularInferface Settings [Schema] [Examples]

These settings are used by providers that depend on scalpel.externals.TabularInterfaces.

Shadowfax

Event Properties [Schema] [Examples]

This schema defines the event properties for each provider. Note that event_types field is added for validation but is not actually with the event properties object. Shadowfax validates the the properties in the _get_event_properties method during augment_events.