Implementation Guidance > Implementation Considerations

Implementation Considerations

This section provides high level implementation guidance for PPR 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 sufficient data (i.e. Minimum search criteria for EMPI match), PPR will return an error.

  • Elements without the "MustSupport" flag in the FHIR request will be ignored by PPR 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 PPR, 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. However, for EMPI Match POST requests, when no Accept or _format parameter is defined, the server uses the Content-Type from the POST request to define the type for the response (XML or JSON per supported MIME-types).

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 EMPI Match: "application/fhir+xml" or "application/fhir+json" Practitioner Search/EMPIm: "application/x-www-form-urlencoded" Not supported in Practitioner Read requests

Letter Case

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

French Characters

Information within PPR 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. In PPR FHIR, the maximum number of practitioner records return is limited to 25 (i.e. Practitioner EMPI Match), Location is limited to 100 therefore paging may not be required

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.

Telecom

For this specification, the telecom string format is defined as digits only with optional extension number in the form of “[country code][area code][local number]” + “ ext. “ + “[extension]".

Examples: “12223334444”, “2223334444”, “12223334444 ext. 1234”.

Given the PPR search algorithm matches on digits only in the local number (disregarding formatting or spacing), historically, it has not enforced a prescribed phone number format at the product level. Consumers must therefore action returned phone values based on local formatting rules.

URI

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