## Implementation Consideration
### Letter Case
Information in Ontario’s EHR assets is stored as mixed case and information is preserved in the format provided by the source (e.g. ALL UPPER CASE, Mixed Case, or a mix). EHR consumers MAY apply data formatting rules where there is a local requirement to standardize information to a consistent format.
### French Characters
Information within Ontario’s EHR assets includes UTF-8 encoded French characters as provided by the source.
### Content Types and Encoding
The formal MIME-type for FHIR resources is application/json+fhir or application/xml+fhir. The correct mime type SHALL be used by clients and servers:
* JSON (preferred): application/json+fhir
* XML (optional): application/xml+fhir
FHIR uses UTF-8 for all request and response bodies. Since the HTTP specification defines a default character encoding of ISO-8859-1, requests and responses SHALL explicitly set the character encoding to UTF-8 using the charset parameter of the MIME-type in the Content-Type header. Requests MAY also specify this charset parameter in the Accept header and/or use the Accept-Charset header.
Accept-Language field in HTTP header will be used to set the language of the search in the future releases. The allowed values are “en-CA” and “fr-CA”. If this field is not set by the requestor, the default is “en-CA”.
## Special Case: Missing data
In some cases, implementers may find that they do not have appropriate data for an element with minimum cardinality = 1. In this case, the element must be present, but unless the resource or a profile on it has made the actual value of the primitive data type mandatory, it is possible to provide an extension that explains why the primitive value is not present:
XML
~~~~
~~~~
JSON
~~~~
"_uri": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
}
~~~~
In this example, instead of a value, a data missing code is provided (https://www.hl7.org/fhir/extension-data-absent-reason.html). Note that it is not required that this particular extension is used. This extension is not a modifier extension, because the primitive data type has no value.
It is not valid to create a fictional piece of data for the primitive value, and then to add an extension indicating that the data has been constructed to meet the data rules. This would be both a bad idea, and also a modifier extension, which is not allowed on data types.
## Data Type Notes
### Date
A date, or partial date (e.g. just year or year + month) as used in human communication. There is no time zone. Dates SHALL be valid dates.
Regex: -?[0-9]{4}(-(0[1-9]|1[0-2])(-(0[0-9]|[1-2][0-9]|3[0-1]))?)?
Example: 1951-06-04
### DateTime
A date, date-time or partial date (e.g. just year or year + month) as used in human communication. If hours and minutes are specified, a time zone SHALL be populated. Seconds must be provided due to schema type constraints but may be zero-filled and may be ignored. Dates SHALL be valid dates. The time "24:00" is not allowed.
Regex: -?[0-9]{4}(-(0[1-9]|1[0-2])(-(0[0-9]|[1-2][0-9]|3[0-1])(T([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00)))?)?)?
Example: 1951-06-04T10:57:34-05:00
### Time
A time during the day, with no date specified (can be converted to a Duration since midnight). Seconds must be provided due to schema type constraints but may be zero-filled and may be ignored. The time "24:00" is not allowed, and neither is a time zone.
Regex: ([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?
### URI
A Uniform Resource Identifier Reference (RFC 3986). Note: URIs are case sensitive. For UUID (urn:uuid:53fefa32-fcbb-4ff8-8a92-55ee120877b7) use all lowercase.
URIs can be absolute or relative, and may have an optional fragment identifier.
### Supported Attributes
Only attributes described in the subsections below will be supported by Panorama ICON. For some elements, cardinality has a superscripted asterisk symbol to the right, e.g. 0..1*: it means that this element has been constraint from “repeated” in the general FHIR spec (e.g. 0..*) to a single instance, but despite this constraint, this should still be represented as an array in a FHIR JSON message, e.g. “element [ {} ]”.
### Format
OLIS will support JSON and XML formats. JSON is the preferred format.
### Slicing
One common feature of constraining Structure Definitions is to take an element that may occur more than once (e.g. in a list), and split the list into a series of sublists, each with different restrictions on the elements in the sublist with associated additional meaning. In FHIR, this operation is known as "Slicing" a list. It is common to "slice" a list into sub-lists each containing just one element, effectively putting constraints on each element in the list. This technique can also be used on elements that do not repeat, but that have a choice of data types.
A number in the brackets after the element name refers to its slicing number.
## Managing Search Parameters
This interaction searches a set of resources based on some filter criteria. The interaction can be performed by several different HTTP commands.
~~~~
GET [base]/[type]{?[parameters]{&_format=[mime-type]}}
~~~~
This searches all resources of a particular type using the criteria represented in the parameters.
All these search interactions take a series of parameters that are a series of name=value pairs encoded in the URL (See W3C HTML forms).
If the search fails (cannot be executed, not that there is no matches), the return value is a status code 4xx or 5xx with an OperationOutcome. If the search succeeds, the return content is a Bundle with type = searchset containing the results of the search as a list of resources in a defined order. The server may also return an OperationOutcome resource with additional information about the search.
### Search Parameter Types
Each search parameter is defined by a type that specifies how the search parameter behaves. These are the defined parameter types:
| Type |Description |
|---|---|
| number | Search parameter SHALL be a number (a whole number, or a decimal). |
| date | Search parameter is on a date/time. The date format is the standard XML format. |
| string | Search parameter is a simple string, like a name part. Search is case-insensitive and accent-insensitive. May match just the start of a string. String parameters may contain spaces. |
| token | Search parameter on a coded element or identifier. May be used to search through the text, displayname, code and code/codesystem (for codes) and label, system and key (for identifier). Its value is either a string or a pair of namespace and value, separated by a pipe, depending on the modifier used. |
### Prefixes
For the ordered parameter types of number, date, and quantity, a prefix to the parameter value may be used to control the nature of the matching. To avoid URL escaping and visual confusion, the following prefixes are used:
| Prefix | Description | Details |
|----|---------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| eq | the value for the parameter in the resource is equal to the provided value | the range of the search value fully contains the range of the target value|
| gt | the value for the parameter in the resource is greater than the provided value | the range above the search value intersects (i.e. overlaps) with the range of the target value |
| lt | the value for the parameter in the resource is less than the provided value |the range below the search value intersects (i.e. overlaps) with the range of the target value |
| ge | the value for the parameter in the resource is greater or equal to the provided value | the range above the search value intersects (i.e. overlaps) with the range of the target value, or the range of the search value fully contains the range of the target value |
| le | the value for the parameter in the resource is less or equal to the provided value | the range below the search value intersects (i.e. overlaps) with the range of the target value or the range of the search value fully contains the range of the target value |
If no prefix is present, the prefix eq is assumed.
## Managing Returned Resources
### Server Conformance
In order to allow the client to be confident about what search parameters were used as criteria by the server, the server will return the parameters that were actually used to process the search. Applications processing search results SHALL check these returned values where necessary. For example, if the server did not support some of the filters specified in the search, a client might manually apply those filters to the retrieved result set, display a warning message to the user or take some other action.
In the case of a RESTful search, these parameters are encoded in the self link in the bundle that is returned:
~~~~
~~~~
In other respects, servers have considerable discretion with regards to supporting search:
* In the future releases, server might declare additional parameter search-id in the profiles referenced from their conformance statements. This search-id would be generated for each search request, logged in audit database along with the search request & search response and returned to the client, who is expected to log this in their audit database too.
* Parameter names and URLs are case-sensitive.
* Server will choose how to sort the return results. In the current release, the _sort parameter will not be supported.
as above.