Implementation Guidance > Implementation Considerations
This section provides high level implementation guidance for PCR.
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 FHIR request does not contain sufficient data (i.e. Minimum search criteria for EMPI match), PCR will return an error.
Elements without "MustSupport" flag in FHIR request will be ignored by PCR 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 meaningful 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 PCR, therefore the consuming application can safely ignore them.
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 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.
Accept-Language field in HTTP header to set the language of the search will be considered for future releases. The current default language for search is English only.
The following header fields should be supported if client system is capable of doing so.
| Header Field | Purpose | Expected Values | Note |
|---|---|---|---|
| Accept | Indicate the type of response expected by the client | application/fhir+xml or applicaiton/fhir+json | If client cannot set this header, they can use _format search parameter in the request URL. If both are provided, _format will be used. |
| Content-Type | Indicate the type of request body in POST requests | EMPI Match: application/fhir+xml or applicaiton/fhir+json Patient Search/PIXm: application/x-www-form-urlencoded | Not used in patient read |
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.
Information within PCR includes UTF-8 encoded French characters as provided by the source.
FHIR RESTful servers may optionally support paging responses when large result set is returned. In PCR FHIR, the maximum number of patient records return is limited to 5 (i.e. Patient EMPI Match), therefore, paging is not required.
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.
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.
Uniform Resource Identifier (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”).
Powered by SIMPLIFIER.NET