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
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:
Submitting Patient Summaries
When submitting a Patient Summary, 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. A Patient Summary instance may not always contain these elements.
Elements without the "MustSupport" flag in a FHIR data submission may be ignored by the Patient Summary Solution. No error will be generated because these elements are present or missing.
Consuming Patient Summaries
Elements marked with "MustSupport" will be supported in accordance with the definition in the profiles for a Patient Summary. 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. When receiving a Patient Summary, elements without the "MustSupport" flag may or may not be stored, viewed, or otherwise processed by the receiving application.
Codeable Concepts in Ontario Patient Summary
The PS-ON makes uses of CodeableConcept datatypes in a variety of fields. CodeableConcepts in PS-ON 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.
Data Formatting
Letter Case
Information in patient summaries 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). Patient Summary consumers MAY apply data formatting rules where there is a local requirement to standardize information to a consistent format.
Extended Character Set
Information within patient summaries 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 is "YYYY-MM-DD" in UTC format. 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-07T13:28:17-05:00 or
- 2015-01-07T18:28:17Z
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 Ontario Patient Summary 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”).