Implementation Guidance Index Conformance Rules
FHIR is a very 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 implementations make similar decisions about what FHIR capabilities those systems will support. FHIR uses the conformance resources to define the actual or expected capabilities of a particular system.
Implementers SHALL consult the FHIR Artifacts pages in this IG to understand the expected capabilities of different systems.
To maximize interoperability, this implementation guide uses MustSupport flag to identify elements that implementers must understand in order to properly submit data in the request and interpret the data in the response. Please refer to the guidance below:
Expectations of systems creating FHIR resources & messages:
Elements marked with the "MustSupport" flag SHALL be populated as defined in the profile and associated business rules. For Direct Messaging integrations, a message without sufficient data to process the event will result in the receiver returning and error.
Elements without "MustSupport" flag are not currently used in referral workflows and MAY not be populated if conformant with cardinality requirements in the profile.
Expectations of systems consuming FHIR resources & messages:
Elements marked with the "MustSupport" flag SHALL be supported by consumers as defined in the profile and associated business rules. If the element is present, the consuming application SHALL handle the element in a meaninful way.(e.g. store it, use it in subsequent workflow or business function)
Elements without "MustSupport" flag in FHIR response are not currently used in referral workflows and MAY be safely ignored.
Information in eReferral 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). eReferral consumers MAY apply data formatting rules where there is a local requirement to standardize information to a consistent format.
Information within eReferral includes UTF-8 encoded French characters as provided by the source.
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:
DateTime (accept two formats)
- 2015-01-07T13:28:17-05:00 or
For this specification, the telecom format is "+[country code]-[area code]-[first three digits of the phone number]-[remaining digits of the phone number] ext."[extension]". Note that if country code is not used, the "+" prefix is skipped.
Example: "+1-555-555-5555 ext. 123456"
Uniform Resource Identifier (URIs) are leveraged in eReferral FHIR messages . URIs are case sensitive. URIs can be absolute or relative, and may have an optional fragment identifier. UUIDs are defined in lower case format (e.g. “urn:uuid:53fefa32-fcbb-4ff8-8a92-55ee120877b7”).