Ontario Medical Imaging HL7® FHIR® Implementation Guide

Implementation Guidance Index > Implementation Considerations

Implementation Considerations

This section provides high level implementation guidance for Ontario MI (Medical Imaging) CDR FHIR implementation.

MustSupport Flag

To maximize interoperability, this implementation guide uses the 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 the "MustSupport" flag in FHIR request must be provided by sending systems in accordance with the profile definition and associated business rules. If the FHIR request does not contain mandatory elements in the profile, MiCDR FHIR interface will return an error. Optional elements marked with "MustSupport" flag SHOULD be provided by sending systems if they have it. However, MiCDR will not generate an error if they are not present.
Elements without the "MustSupport" flag in the FHIR request will be ignored by MiCDR and no error will be generated because these elements are present.
Elements marked with the "MustSupport" in the 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 meaningful way (e.g. store it and use it in subsequent workflow or business function).
Elements without the "MustSupport" flag in the FHIR response will not be populated by MiCDR, therefore the consuming application can safely ignore them.

Content Type and Encodings

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

• JSON(preferred): application/fhir+json

• XML: application/fhir+xml

When no MIME-type is specified in the Accept or _format parameter in the GET request, JSON will be returned in the response.

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.

HTTP Header Fields

The following HTTP header fields should be defined on the request if the client system is capable of doing so:

Header Field	Purpose	Expected Values	Notes
Accept	Indicates the type of response expected by the client	"application/fhir+xml" or "applicaiton/fhir+json"	If the client cannot set this header, the " _format" search parameter can be used as an alternative in the request URL. If both are provided, the “_format” search parameter will take precedence.
Content-Type	Indicates the type of request body in POST requests	"application/fhir+xml" or "application/fhir+json"	Not supported in GET requests

Letter Case

Information in MiCDR 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). Consumers of MiCDR FHIR interface MAY apply data formatting rules where there is a local requirement to standardize information to a consistent format.

French Characters

Information within MiCDR includes UTF-8 encoded French characters as provided by the source.

Paging

The server provides next set for the results of a search interaction for sending continuation links to the client when returning a Bundle. This example shows the next page of a search result:


<Bundle xmlns="http://hl7.org/fhir">
  <!-- snip metadata -->
  <!-- This Search. url starts with base search, and adds the effective
    parameters, and additional parameters for search state. All searches
    SHALL return this value.

	  In this case, the search continuation method is that the server
    maintains a state, with page references into the stateful list.
	-->
  <link>
    <relation value="self">


    <url value="[base]/$docref?patient.identifier=[id-system-global-base]/ca-on-patient-hcn|1008624486&patient.gender=male&patient.birthdate=1929-11-29&issued=ge2016-01-02&_count=10&search-id=017-11-16T20:37:03.0000000X128987"/>
  </link>

  <link>
    <relation value="next"/>
    <url value="[base]/$docref?patient.identifier=[id-system-global-base]/ca-on-patient-hcn|1008624486&patient.gender=male&patient.birthdate=1929-11-29&issued=ge2016-01-02&_count=10&search-id=017-11-16T20:37:03.0000000X128987"/>
  </link>

  <!-- then the search results... -->
</Bundle>

A server will inform the client of the total number of resources returned by the interaction for which the results are paged using the Bundle.total.

FHIR Data Type Format

Date

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. Note that "YYYY-MM-DD" must be followed exactly and no other format will be accepted.

URI and OID

Uniform Resource Identifiers (URIs) are leveraged in MiCDR FHIR messages for identifiers. 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”).

Some local identifier assigning authority might still use OIDs to avoid unnecessary workload for implementers. For example, local document identifiers might still use OIDs that were already used in the legacy solution. For details of identifier use, please refer to the Identifier Page for details.