The TRT API allows client applications to maintain TRT data record sets.
This developer's guide is intended for software developers needing a technical reference for using the QBOS REST API. The information you find in this guide is written by software engineering, and is authoritative on how the API behaves.
Occasionally, we make a mistake in this documentation, or unknowingly break a feature that you depend on. If this has happened to you, we apologize! You can help us fix the issue by contacting us at: pkajaani@qbos.com. We appreciate your help.
To place any request in a QBOS API application from a third party application you need to first authenticate your user account and set/calculate values for the following request headers:
x-qbos-id, x-qbos-nonce, x-qbos-date-utc, x-qbos-hash-version, x-qbos-auth
See details in Authentication Documentation.
Custom resource (a.k.a applet) URI contains the resource vendor id in place of "/o/" in the standard object URI.
Compare:
.../v1/o/...with .../v1/{vendor_id}/...
Properties prefixed with '_' (underscore) are read-only properties. i.e. POST and PUT processing will ignore these properties.
| Name | Type | Max Length |
Numeric | Required For POST |
Filterable | Default | Description |
|---|---|---|---|---|---|---|---|
| _client_Id | bigint | Yes | NULL | This is the Data Org Id. | |||
| _owner_Id | bigint | Yes | Yes | NULL | This is the user id of the record owner. Defaults to the creatorOpid. | ||
| _creator_Opid | bigint | Yes | Yes | NULL | This is the user id of the original record submitter. | ||
| _create_Date | datetime | No | {timestamp} | Not enterable upon Insert. System sets this date upon record creation. | |||
| status_id | int | Yes | Yes | 4827 | The status id of the record. Taken from the Life Cycle statuses in ADS. | ||
| _status_Change_Date | datetime | No | NULL | Not enterable. System sets this date whenever the statusid is changed. | |||
| Start_Date | datetime | Yes | NULL | ||||
| Stop_Date | datetime | Yes | NULL | ||||
| Treatment | nvarchar | 255 | Yes | NULL | |||
| Frequency | nvarchar | 255 | Yes | NULL | |||
| Coverage | bit | Yes | Yes | NULL |
This property is populated by a Type 1 Value List. Click here for the appropriate API and sample of value options for this column. |
||
| Careplan | nvarchar | 20 | Yes | NULL | |||
| Teaching_Date | datetime | Yes | NULL | ||||
| Patient_Last_Name | nvarchar | 25 | Yes | NULL | |||
| Patient_First_Name | nvarchar | 25 | Yes | NULL | |||
| Client_Type | nvarchar | 10 | Yes | NULL | |||
| PDC_CLient_ID | nvarchar | 30 | Yes | NULL | |||
| Group_ID | nvarchar | 30 | Yes | NULL | |||
| Last_User | nvarchar | 20 | Yes | NULL | |||
| Medication_Covered | bit | Yes | No | 0 |
This property is populated by a Type 1 Value List. Click here for the appropriate API and sample of value options for this column. |
Parent and Child relations to TRT.
Note that the only Required status on relationships that affect a POST of an object are on the parent relations. A Required status on a child relation is only meaningful when POSTing the child object.
Linking during POST: a custom object record can be linked to a parent or child record (custom or standard) during POST by including (in the payload) the realtion id paired with the parent or child object record being linked to. For example: { "REl_2666" : 1832 } Multiple links may be created in the same POST.
| Relation Id | Cardinality (Parent-to-Child) |
Required For POST |
Links Up To | Is Unary?* |
|---|---|---|---|---|
| REL_2666 | 1-Many | Yes | Patient_Facesheet | |
| Parent Relations ↑ TRT ↓ Child Relations | ||||
| Relation Id | Cardinality (Parent-to-Child) |
Required **on POST of child |
Links Down To | |
Request data [See properties]:
Response codes:
Request data [See properties]:
Response codes:
The "id" in JSON payload is required to match the {id} in the URI to ensure that deletion requests are intended and safe
Response codes:
Response codes:
Response codes: