visit the hl7 website
Ontario Provincial Consent Override Interface HL7® FHIR® Implementation Guide v1.0.0-draft1
fhir-logo
  • Index
  • Home
    • Home
    • Introduction
    • Relationship to Other Specifications
    • Scope
    • Glossary
  • Business Context
    • Business Context
    • Business Model
    • Business Data
    • Use Cases
    • Business Rules
  • Technical Context
    • Technical Context
    • Implementer Responsibility
    • Conformance Rules
    • Connectivity Summary
  • FHIR Artifacts
    • FHIR Artifacts
    • Interactions
    • Profiles
    • Extensions
    • Terminology
    • System URIs
    • Examples
    • Capability Statement
    • Response Handling
    • Downloads
  • Change Log
    • Change Log
    • Known Issues & Future Developments
    • Revision History
    1. Index
    2. Technical Context
    3. Conformance Rules

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

3.2.1.1. Submitting Consent Request

When submitting a Consent request, 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.

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

3.2.2. Implementation Considerations for PCOI

3.2.3. MustSupport Flag

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:

Elements marked with "MustSupport" flag in FHIR request must be provided by sending systems in accordance with the profile definition and associated business rules, if the element is available.

Elements without "MustSupport" flag in FHIR request or data submission will be ignored by PCOI and no error will be generated because these elements are present.

Elements marked with "MustSupport" in FHIR response will be supported in accordance with the definition in the profile. 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 will not be populated by PCOI, therefore the consuming application can safely ignore them.

This section provides high level implementation guidance for PCOI.

3.2.4. Content Type and Encodings

3.2.4.1. MIME-Type

The formal MIME-type for FHIR resources is application/fhir+json. The correct mime type SHALL be used by clients and servers:

* JSON: application/fhir+json

Only JSON will be returned in the response, also using the mimetype application/fhir+json. This applies to the Consent Create interaction.

3.2.4.2. Encoding

FHIR uses UTF-8 for all request and response bodies. Since the HTTP specification defines a default character encoding of ISO-8859-1, requests and responses SHALL explicitly set the character encoding to UTF-8 using the charset parameter of the MIME-type in the Content-Type header. Requests MAY also specify this charset parameter in the Accept header and/or use the Accept-Charset header.

3.2.4.3. Accept-Language

The language for the Create Consent interaction is English only.

3.2.5. Data Formatting

3.2.6. Letter Case

Information in PCOI are stored as mixed case and information is preserved in the format provided by the source (e.g. ALL UPPER CASE, Mixed Case, lower case).

3.2.7. Extended Character Set

Information within Document Objects shall be in UTF-8 to support extended characters beyond standard ASCII/ANSI character set including French characters.

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

3.2.9. 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.10. URI/UUID

Uniform Resource Identifiers (URIs) leveraged in PCOI FHIR resources 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”).

Version: 1.0.0 FHIR Version: R4.0.1

Powered by SIMPLIFIER.NET

HL7® and FHIR® are the registered trademarks of Health Level Seven International