API Reference

General Guidance

The general syntax for API interactions described here.

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

The Section define the rules for servers and clients that support the RESTful interactions defined in this Documentation.

All the 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
      • {¶meter2={:m1 m2 …}={c1 c2 …}[value1{,value2,…}&…}: Optional multiple ‘AND’ search parameters

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, the Observation resource the name “code” for search on the LOINC code.

SMART-ON-FHIR

For the SMART-ON-FHIR implementation for patient scopes, e.g. patient/Observation.read (smart-on-fhir version 1.0.0) the search always implicits by search parameter patient automatically by the server.