Implementation Guidance > Implementation Considerations

Implementation Considerations

This section provides high level implementation guidance for PCR 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), PCR will return an error.

• Elements without the "MustSupport" flag in the FHIR request will be ignored by PCR 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 PCR, 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+xmlWhen no MIME-type is specified in the Accept or _format parameter in the GET request, JSON will be returned in the response. However, for Patient 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 PCR. 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 "application/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" Patient Search/PIXm: "application/x-www-form-urlencoded"	Not supported in Patient Read requests

Letter Case

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

French Characters

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

Paging

FHIR RESTful servers may optionally support paging responses when a large result set is returned. In PCR FHIR, the maximum number of patient records returned in a given response is limited to 5 (per Patient EMPI Match), therefore, paging is not supported

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 PCR 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 PCR FHIR messages for patient 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”).