> ## Documentation Index
> Fetch the complete documentation index at: https://help.elationhealth.com/llms.txt
> Use this file to discover all available pages before exploring further.

# General Guidance

This article describes the general syntax for API interactions.

## Using UCUM codes in the Quantity datatype

Both the [US Core Vital Signs Profile](/articles/fhir/uscdi-vital-signs) and [US Core Laboratory Result Observation Profile](/articles/fhir/uscdi-laboratory-results-observation) bind the `valueQuantity` data types to the [UCUM](http://unitsofmeasure.org/) code system. A FHIR UCUM Codes value set that defines all UCUM codes is in the FHIR specification. This guidance specifies how to represent the Quantity datatype when the correct UCUM units are missing or the units are missing altogether which will likely occur in the real world.

**UCUM code provided:**

```
 "valueQuantity": {
    "value": 26.0,
    "unit": "g/mL",
   "system": "http://unitsofmeasure.org",
   "code": "g/mL"
  }
```

**free text units only:**

* If UCUM units are not available then represent units in the unit element.

```
 "valueQuantity": {
    "value": 26.0,
    "unit": "RR",
     }
```

**no units:**

```
 "valueQuantity": {
    "value": 26.0
 }
```

## Read (Fetch) Syntax

For fetching a resource, interactions on documentation pages are defined with the following syntax:

`GET [base url]/[Resource-type]/[id] {parameters}`

* `GET` is the `HTTP` verb used for fetching a resource
* Content surrounded by \[] is mandatory for the client to supply, and will be replaced by the string literal identified.
  * `base url`: The Service Root URL (e.g. `https://sandbox.fhir.elationemr.com/fhir`)
  * `Resource-type`: The name of a resource type (e.g. `Patient`)
  * `id`: The Logical Id of a resource(e.g. `24342`)
* Content surrounded by `{}` is optional for the client to supply, and will be replaced by the string literal identified.
  * parameters: URL parameters as defined for the particular interaction (e.g.`?_format=xml`)

For more information see the [FHIR RESTful API](/articles/fhir/kodjin-restful-api)

**Example**:

```
`https://sandbox.fhir.elationemr.com/fhir/Patient/24342`
```

## Search Syntax

This section defines the rules for servers and clients that support the RESTful interactions defined in this documentation.

All search interactions in this guide use the GET command with the following syntax:

```
GET [base url]/[Resource-type]?[parameter1]{:m1|m2|...}={c1|c2|...}[value1{,value2,...}]{&[parameter2]{:m1|m2|...}={c1|c2|...}[value1{,value2,...}]&...}
```

* `GET` is the `HTTP` verb used for fetching a resource
* Variables surrounded by “\[]” are mandatory for the client to supply, and will be replaced by the string literal identified.
* Variables surrounded by “\{}” are optional for the client to supply, and will be replaced by the string literal identified.
  * base url: The Service Root URL (e.g. `https://sandbox.fhir.elationemr.com/fhir`)
  * Resource-type: The name of a resource type (e.g. `Patient`)
  * parameter: the search parameters as defined for the particular interaction (e.g.`?patient=Patient/123`)
  * value: the search parameter value for a particular search
    * When searching using the token type search parameter [how to search by token](http://hl7.org/fhir/R4/search.html#token), the syntax `{system|}[code]` means that the system value is optional for the client to supply.
    * When searching using the reference type search parameter [how to search by reference](http://hl7.org/fhir/R4/search.html#reference), the syntax `{Type/}[id]` means that the `Type` value is optional for the client to supply.
    * When searching using the `date` search parameter [how to search by date](https://hl7.org/fhir/search.html#date), the syntax `date={gt|lt|ge|le}[date]` means the date comparators “*gt*”, “*lt*”, “*ge*”, and “*le*” are optional. Date type searches without a comparator prefix are equivalent to searches with the “*eq*” comparator even if a server does not support the comparator.
    * \{:m1	m2	…}: The list of supported search parameter modifiers
    * \{c1	c2	…}: The list of supported search parameter comparators
    * \{,value2,…}: Optional multiple ‘OR’ Values
    * **Additional AND parameters:** In the GET line above, the portion starting with `&[parameter2]` shows how to chain more search parameters using `&`. Each chained segment repeats the same `[parameter]{:modifiers}={comparators}[values]` shape as the first parameter block.

In the simplest case, a search is executed by performing a GET operation in the RESTful framework:

`GET [base]/[Resource-type]?name=value&...`

For this RESTful search, the parameters are a series of name=\[value] pairs encoded in the URL. The search parameter names are defined for each resource. For example, for the Observation resource, the name “code” is used to search on the LOINC code.

### SMART-ON-FHIR

For the SMART on FHIR implementation with `patient` scopes (for example, `patient/Observation.read`; see [SMART App Launch 1.0.0](https://hl7.org/fhir/smart-app-launch/1.0.0)), the server evaluates searches in the **authorized patient context**: explicit search parameters are applied **within** that patient binding, consistent with the SMART rules for `patient/` scopes.