For a full list of available versions, see the Directory of published versions

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

---

3.2.2. 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:

---

3.2.2.3. Submitting Data

When submitting an IAR assessment form, the source system (e.g. HICs Data Contributor System):

Elements without the "MustSupport" flag

• SHOULD not be included in the FHIR submission. If included, these elements will not be stored in the receiving system.

Elements marked with "MustSupport"

• SHALL demonstrate capability to provide these elements in accordance with the profile definition and associated business rules. Each FHIR resource instance may not always include all MustSupport elements.

---

3.2.2.4. Consuming Data

For consuming applications:

Elements without the "MustSupport" flag

• SHALL not be persisted unless specifically required for care and supported by policy.

Elements marked with "MustSupport"

• SHOULD be capable of handling in a meaningful way (e.g. store it, use it in subsequent workflow or business function), and
• SHALL be capable of processing without generating an error or causing the application to fail.
• SHALL be able to process data elements asserting missing information (i.e. data-absent-reason).

Processing includes:

• Storing data
• Rendering for human review
• Supporting domain-specific workflows

---

3.2.3. Codeable Concepts

Codeable Concepts are made up of two elements: a coding and a text element. For this specification, both coding and text are considered MustSupport but not mandatory. This means that, in order to be compliant with the MustSupport flag in the specification, systems must be able to demonstrate the ability to generate both coding and text for any elements with the CodeableConcept data type. Since neither element is considered mandatory, not all instances of a given resource are expected to contain a coding; instances may be sent with only a text element if coding is not available. At least one of coding or text must be present in order to form a valid CodeableConcept.

---

3.2.4. Data Formatting

---

3.2.4.1. Letter Case

Information in IAR 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). IAR consumers MAY apply data formatting rules where there is a local requirement to standardize information to a consistent format.

---

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

---

3.2.4.3. Leading and trailing white-spaces (TBD)

Do not include leading and trailing whitespaces for identifier fields.

---

3.2.5. Data Type Notes

3.2.5.1. Date

A date as used in human communication. There is no time zone. Dates SHALL be valid dates.

Example: 1951-06-04

---

3.2.5.2. 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: The IAR data contributor or sending system submitting the assessment form should use their local time zone whenever time information is sent in contributions. For example, if a HIC application in Ontario is in Central Time Zone, then time information sent will be based on their local time and specifying the central time zone.

---

3.2.5.3. 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"

---

3.2.5.4. URI/UUID

Uniform Resource Identifiers (URIs) leveraged in the IAR 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”).