Cortex objects are containers for data and functionality. For data-modeling purposes, you can think of a Cortex object like a database table. However, Cortex objects come with many more inherited capabilities than just data storage. For example, a Cortex object lets you specify fine-grained access controls for the objects and their properties, they allow for sharing data with others using connections, you can sub-class Cortex objects into multiple types, and you can extend objects with custom logic via triggers.
Cortex provides a number of standard objects to get you going. You can also create your own objects for modeling your own data and creating your own functionality to meet your needs however you see fit.
$ The Account Object represents a user account within an Organization.
The Organization object represents the org, itself.
Connections enable access to an object instance for a target. For more details, see Using Connections
Notifications are created when persistent notifications are sent. They contain meta-data about notifications that can facilitate notification handling in client apps.
The Object object contains the definitions for custom and extended Cortex objects.
You can extend standard objects by adding custom properties. You can do this via the admin UI and also directly via the Object API.
For example, if you'd like to track the most recent app login for a particular user, you might add a
c_last_logged_inproperty that is a Date type to the Account standard object. Now, every user that registers in your app can be stored in the backend with this additional date property. You can pass in the
c_last_logged_inparameter and the Medable API will know to store that field in a given Account.
You can add any number of custom properties of varying types to get the desired functionality for your application.
You can extend the API by creating new custom objects and with custom properties, You can do this via the admin UI and also directly via the Object API.
Custom Cortex object and property names are prefixed with
c_to differentiate them from standard objects and properties. Additionally, custom objects are given a plural name along with the name you provide. So, for example if you create a custom objects named patient, the api name of your object will be
c_patientand the plural name will be
c_patients. If you were to create a custom name document property on your
c_patientobject, with sub string properties of first and last, then your
c_patientobject could look something like:
Although a standard object's standard properties cannot be modified, custom properties can be added to extensible standard objects.