Ontario Provenance HL7® FHIR® Implementation Guide -v1.0.0-trial-use
For a full list of available versions, see the Directory of published versions
Technical Context > 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.3.2. 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.3.4. When submitting data to Ontario Health, the source system must demonstrate that it is capable of providing the elements marked with the "MustSupport" flag and be configured to include these data elements 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 they won't be stored.
3.3.6. Elements marked with "MustSupport" will be supported in accordance with the definition in the profiles. 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 might not be stored, viewed, or otherwise processed by the receiving application unless there is condition to indicate that the element should be displayed, stored, or otherwise processed if possible.
3.3.8. Letter Case Information 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). Implementers MAY apply data formatting rules where there is a local requirement to standardize information to a consistent format.
3.3.10. All information exchanged within Ontario’s EHR assets SHALL be encoded using UTF-8 to support extended character sets beyond ASCII/ANSI, including French characters.