Skip to main content
This article describes the general syntax for API interactions.

​
Using UCUM codes in the Quantity datatype

Both the US Core Vital Signs Profile and US Core Laboratory Result Observation Profile bind the valueQuantity data types to the UCUM 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 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, 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, 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, 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), 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.