Conformance Rules

FHIR is a general purpose specification and imposes no particular requirements on implementers to support specific resources, operations, search parameters or other capabilities. To achieve interoperability in a particular domain, it's important that implementors make similar decisions about what FHIR capabilities those systems will support. FHIR uses the Conformance resource to define the actual or expected capabilities of a particular system.The contents of a resource and the formats used to represent resources SHALL conform to the rules described in FHIR specification, as defined in the narrative of the specification, and as controlled by the conformance properties defined at:https://www.hl7.org/fhir/conformance-rules.htmlData elements defined in resources and data types have three properties that are directly related to conformance: Cardinality, Is-Modifier, and Must-Support. These interact to place conformance requirements on implementations.

Identifiers

Within OLIS, there is a broad range of concepts including patients, providers, organizations, systems, diagnostic procedures, test requests and results that require accurate identification.Identifiers relevant to this interface include:• Organization Identifiers and Service Provider Identifiers• Patient Identifier is used to identify the person to whom the PHI belongs and is issued by Service Ontario and referred to as the Ontario Health Card• Terminology: the various coded values which are used to describe clinical concepts within health records as well as codes used within messages to meet the structural requirements of interfaces.

Test Request Nomenclature Valid Test Request code(s) in the most recent OLIS Nomenclature file published
Test Result Nomenclature: Valid Test Result code(s) in the most recent OLIS Nomenclature file published
Specimen Source: Specimen Source code(s) in the most recent OLIS Nomenclature file published

(Refer to the latest OLIS Nomenclature file)

MustSuport Flag

To maximize interoperability, this implementation guide uses the MustSupport flag to identify elements that implementers must understand in order to properly submit, process, or view . Please refer to the guidance below:

Creating OLIS Records

When creating or updating OLIS record , a system must demonstrate that it is capable of providing the elements marked with the "MustSupport" flag in accordance with the profile definition and associated business rules. An OLIS record instance may not always contain these elements.Elements without the "MustSupport" flag in a FHIR data submission may be ignored by OLIS. Unless there is written implementation guidance to indicate that an element is considered optional and may be sent if available, the element should not be present in the message. No error will be generated because these elements are present or missing.Note: Creating OLIS record with FHIR is not supported in the current release.

Receiving OLIS Records

Elements marked with "MustSupport" will be supported in accordance with the definition in the profiles for OLIS records. Consuming applications SHALL be capable of processing resources containing MustSupport data elements without generating an error or causing the application to fail. Consuming applications SHOULD be capable of handling the MustSupport data elements in a meaningful way (e.g. store it, use it in subsequent workflow or business function), and SHALL be able to process instances containing MustSupport data elements asserting missing information.Elements without the "MustSupport" flag when receiving OLIS records might not be stored, viewed, or otherwise processed by the receiving application unless there is implementation guidance to indicate that the element is considered optional, in which case it should be displayed, stored, or otherwise processed if possible.

Data Formatting

Letter Case

Information in OLIS is stored as mixed case and information is preserved in the format provided by the source (e.g. ALL UPPER CASE, Mixed Case, lower case). OLIS consumers MAY apply data formatting rules where there is a local requirement to standardize information to a consistent format.

Extended Character Set

Information within OLIS shall be in UTF-8 to support extended characters beyond standard ASCII/ANSI character set including French characters.

Date

In this specification, the expected date format are "YYYY-MM-DD" and "YYYY MM DD". If this format is not provided, or an invalid date is provided in the defined format, the request will be rejected. Below are the formats supported:DateTime (accept two formats)

2015-01-07
2015 01 07

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?(Z|(+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00)))?)?)?Example: 1951-06-04T10:57:34-05:00

Telecom

For this specification, the telecom format is "+[country code]-[area code]-[exchange]-[subscriber number] ext."[extension]". Note that if country code is not used, the "+" prefix is skipped.Example: "+1-555-555-5555 ext. 123456"

URI/UUID

Uniform Resource Identifiers (URIs) leveraged in OLIS are case sensitive. URIs can be absolute or relative, and may have an optional fragment identifier. Universally Unique IDs (UUIDs) are defined in lower case format (e.g. “urn:uuid:53fefa32-fcbb-4ff8-8a92-55ee120877b7”).

FHIR Usage Notes

Content Types and Encoding

The formal MIME-type for FHIR® resources is application/fhir+json or application/fhir+xml. The correct mime type SHALL be used by clients and servers for each query:

OLIS FHIR Patient Query For Providers:
- JSON (preferred): application/fhir+json
- XML (optional): application/fhir+xml

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.

FHIR Versioning

OLIS FHIR interface will provide FHIR STU3 and FHIR R4 capability from the same endpoint. In order to support different FHIR versions, clients using FHIR R4 must provide fhirVersion in the request Accept header field as shown below. If this field is not present, OLIS FHIR interface will provide FHIR STU3 content. GET [base]/DiagnosticReport[?search-parameters] Accept: application/fhir+json; fhirVersion=4.0

Search 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.