Implementation Guidance > Implementation Considerations

Implementation Considerations

This section provides high level implementation guidance for CDR FHIR.

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, CDR FHIR interface will return an error. Optional elements marked with "MustSupport" flag SHOULD be provided by sending systems if they have it. However, CDR will not generate an error if they are not present.

  • Elements without the "MustSupport" flag in the FHIR request will be ignored by CDR 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 CDR, 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.

Use of the Accept-Language HTTP header on the request is currently not supported by the PPR. The current default language for search is English only.

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 CDR 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 CDR FHIR interface MAY apply data formatting rules where there is a local requirement to standardize information to a consistent format.

French Characters

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

Paging

FHIR RESTful servers may optionally support paging responses when large result set is returned.

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. Below are the formats supported:

  • 2015-01-07T13:28:17-05:00 or
  • 2015-01-07T18:28:17Z

For submitted data, it can be in either of the formats specified – either in the local time with the correct UTC offset (e.g. 2015-01-07T13:28:17-05:00) OR if no offset is provided, it must be provided in UTC like 2015-01-07T18:28:17Z. The “Z” suffix designates that this datetime is in UTC with no offset, so these two examples represent the same time. The date will be saved in UTC, which allows any viewers to translate the stored time into their appropriate local timezone based on the offset from UTC.

URI and OID

Uniform Resource Identifiers (URIs) are leveraged in CDR 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 will still use OIDs to avoid unnecessary workload for implementers. For example, local encounter identifiers and document identifiers will still use OIDs that were already used in the legacy solution. For details of identifier use, please refer to the {Identifiers page](Identifiers) for details.