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.

Implementation Consideration

Within DHDR, there is a broad range of concepts including patients, providers, organizations, systems, and medications that require accurate identification.

Identifiers relevant to this interface include:

• Organization Identifiers and Service Provider Identifiers

• Patient Identifier is used to identify the person. It can be issued by:

  • Service Ontario and referred to as the Ontario Health Card
  • Hospital and referred to as the Medical Record Number
  • Pharmacy and referred to as the Pharmacy Management System (PMS) unique identifier

• Terminology: the various coded values which are used to describe clinical concepts within health records as well as codes used within messages to meet the structural requirements of interfaces.

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 DHDR data

When submitting a DHDR data, 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 DHDR instance may not always contain these elements.

Elements without the "MustSupport" flag in a FHIR data submission may be ignored by the DHDR Solution. No error will be generated because these elements are present or missing.

Consuming DHDR 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.

Regex: -?[0-9]{4}(-(0[1-9]|1[0-2])(-(0[0-9]|[1-2][0-9]|3[0-1]))?)?

Example: 1951-06-04

DateTime

A date or date-time as used in human communication. If hours and minutes are specified, a time zone SHALL be populated. Seconds must be provided due to schema type constraints but may be zero-filled and may be ignored. Dates SHALL be valid dates. The time "24:00" is not allowed.

Regex: -?[0-9]{4}(-(0[1-9]|1[0-2])(-(0[0-9]|[1-2][0-9]|3[0-1])(T([01][0-9]|2[0-3]):[0-5][0-9]:[0-5]0-9?(Z|(+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00)))?)?)?

Example: 1951-06-04T10:57:34-05:00

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”).