FHIR is a very 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 implementations 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.
Ontario Health does not have any specific conformance expectations for CMS client systems beyond the security requirements defined through the onboarding process. This means that client systems are free to decide which operations they wish to support, which optional search parameters they want to use and what data elements they want to make use of and how they wish to use those elements (within the constraints set by their access agreement with Ontario Health).
Within the profiles included in this implementation guide, "Must Support" indicates that those data elements are currently used by the Ontario CMS when receiving instances and populated (when data exists) when producing instances. Non-supported data elements will be ignored as inputs and will not be populated in responses. However, support for these elements may be introduced in the future.
To maximize interoperability, this implementation guide uses MustSupport flag to identify elements that implementers must understand in order to properly submit data in the request and interpret the data in the response. Please refer to the guidance below:
Elements marked with "MustSupport" flag in FHIR request/response must be provided by sending/receiving systems in accordance with the profile definition and associated business rules. If the FHIR request does not contain sufficient data CMS will return an error.
Elements without "MustSupport" flag in FHIR request or data submission will be ignored by CMS and no error will be generated because these elements are present.
Elements marked with "MustSupport" in FHIR response will be supported in accordance with the definition in the profile. If the element is present, the consuming application SHALL handle the element in a meaningful way.(e.g. store it, use it in subsequent workflow or business function)
Elements without "MustSupport" flag in FHIR response will not be populated by CMS, therefore the consuming/receiving application can safely ignore them.
Information in CMS 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). CMS consumers MAY apply data formatting rules where there is a local requirement to standardize information to a consistent format.
Information within CMS includes UTF-8 encoded French characters as provided by the source.
In this specification, the expected date format is "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:
Date:
DateTime (accept two formats)
For this specification, the telecom format is "+[country code]-[area code]-[first three digits of the phone number]-[remaining digits of the phone number] ext."[extension]". Note that if country code is not used, the "+" prefix is skipped.
Example: "+1-555-555-5555 ext. 123456"
Uniform Resource Identifier (URIs) are leveraged in CMS FHIR messages . URIs are case sensitive. URIs can be absolute or relative, and may have an optional fragment identifier. UUIDs are defined in lower case format (e.g. “urn:uuid:53fefa32-fcbb-4ff8-8a92-55ee120877b7”).
Powered by SIMPLIFIER.NET