Implementation Guidance Index > Conformance Rules
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 CapabilityStatement resource to define the actual or expected capabilities of a particular system.
MustSupport Flag
FHIR standard utilizes MustSupport flag to identify data elements that implementers must support in order to produce or consume FHIR resources in some meaningful way. Please refer to the guidance below:
Submitting Data
When submitting data to Ontario Health, the source 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. Each FHIR resource instance may not always contain these elements.
Elements without the "MustSupport" flag should not be included in a FHIR submission. If included it won't be stored in DHDR Solution.
Consuming Data
Elements marked with "MustSupport" will be supported in accordance with the definition in the profiles for the DHDR. 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 from DHDR 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 DHDR 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). DHDR consumers MAY apply data formatting rules where there is a local requirement to standardize information to a consistent format.
Extended Character Set
Information within Ontario’s EHR assets includes UTF-8 to support extended characters beyond standard ASCII/ANSI character set including French characters.
Data Type Notes
Date
A date as used in human communication. There is no time zone. Dates SHALL be valid dates.
Example: 1951-06-04
DateTime
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:
- 1951-06-04T10:57:34-05:00
- 2015-01-07T18:28:17Z
For submitted data, it can be in either of the formats specified – either in the local time with the correct UTC offset (e.g. 2015-01-07T13:28:17-05:00) OR if no offset is provided, it must be provided in UTC like 2015-01-07T18:28:17Z. The “Z” suffix designates that this datetime is in UTC with no offset, so these two examples represent the same time. The date will be saved in UTC, which allows any viewers to translate the stored time into their appropriate local timezone based on the offset from UTC.
Note: Pharmacies or hospitals submitting data should use their local time zone whenever time information is sent in contributions. For example, if a pharmacy in Ontario is in Central Time Zone, then time information sent will be based on their local time and specifying the central time zone.
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 the DHDR 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”).