HealthcareService

Profiles & Operations > HealthcareService Search

HealthcareService search is simple RESTful interactions. It support retrieving a single HealthcareService instance by HealthcareService Identifier and the list of request parameters defined in 'specification' section of this page.

Scope

This transaction involves a request by a FHIR Provider RESTful Client for information about Healthcareservice.The request is received by the FHIR Provider server. The server immediately processes the request and returns a FHIR Bundle containing a list of potentially matching HealthcareService.

This transaction involves a request by the following Identifiers for:

HealthcareService:

Source Identifier
Host Listing System URI Host Listing System Unique Identifier

Interaction Diagrams

The following diagram illustrates the high level interaction between a FHIR Client and FHIR Provider RESTful Server. In this implementation guide, Provincial Provider Registry is playing the role of the FHIR Provider RESTful Server. All subsequent references of this actor (FHIR Provider RESTful server) should be interpreted as the Provincial Provider Registry.

The Provider FHIR transaction will use the following query and response:

• HealthcareService Search Request /HealthcareService Search Response

Command 'tree' could not render: Project was not found for provincialproviderre/healthcareservicesearch-png.

Actor: FHIR Provider RESTful Client

Role: Requestor

Requests a detailed profile of a single HealthcareService based on a known HealthcareService ID Issuer from the FHIR Provider RESTful Server. The FHIR Client uses the information received from the FHIR Provider RESTful Server for its own purposes. The RESTful client is referred to as the “FHIR client” in the remainder of the document.

Actor: FHIR Provider RESTful Server

Role: Information Service

Returns a bundle containing the demographic information for the single healthcareService corresponding to the Issuer & ID values specified by the FHIR Provider RESTful Client. This actor is referred to as the FHIR server in the remainder of the document.

Specification

This FHIR spec is based on the HL7 STU3 Search operation. It makes use of the following resources:

Provider healthcareService Search Request

The provider healthcareService Search Request is an HTTP POST operation with exactly one query parameter specified below. The syntax of the request is always

POST [base]/HealthcareService?identifier=[system]|[value]

Provider healthcareService Search Response

General

The PPR FHIR profiles are developed to constrain value sets and cardinality of data elements in the resources listed above. Since FHIR STU3 does not support all the data elements required for this project, we have introduced a few extensions which can be found here.

Extensions

Summary of Supported Operations

The table below shows the allowed transactions for each profile and how they support FHIR endpoints, resources and their corresponding HTTP operations:

Resource Transaction HTTP Operations URL Request Body Resource Response Body Resource
Healthcareservice Search POST [base]/Healthcareservice? N/A Bundle containing Healthcareservice

The interaction summary table below lists the HTTP status codes that may be returned for the search.

Interaction Content-Type Body Location Versioning Status Codes Comments
Search (Healthcareservice) R R: Bundle N/A N/A 200,400,500

Healthcareservice Search Operations

The Healthcareservice search is invoked through a HTTP POST request specifying the issuer (e.g. URI of PPR EPID, CPSO etc.) and identifier value (EPID, UPI, etc.) of a single Healthcareservice instance. The response from the FHIR Provider RESTful Server will be a Healthcareservice Resource, or in the case of a failed search, an operation outcome resource.

Trigger Event

When a FHIR Client has the identifiers for an Healthcareservice but does not yet have the name, contact, license and other information or wishes to retrieve an updated version of the Healthcareservice's information, it invokes an Healthcareservice search.

Expected Behaviour

The FHIR Server shall return the records that correspond to the "Issuer/identifier" combination used in the request by the FHIR Provider RESTful Client. The FHIR Server shall respond synchronously (i.e. on the same connection as was used to initiate the request).

The FHIR Server shall respond to the search request as described by the following cases and shall behave according to the use-cases listed below:

Case Scenario Description Response
1 PPR finds in its information source, a healthcareService that matches the id specified by the FHIR Client Application HTTP 200 (OK) is returned as the HTTP status code. A bundle is returned that contains the a healthcareService
2 PPR cannot find an a healthcareService that meets the search parameter specified by the FHIR Client Application HTTP 200 (OK) is returned as the HTTP status code. An empty bundle is returned
3 PPR detects an error in the request and could not fulfill the request HTTP 400(Bad Request) is returned as the HTTP status code. The body contains an OperationOutcome with error details.
4 PPR validates the request but cannot return valid response due to internal issue. HTTP 500 (Internal Server Error) is returned as the HTTP status code. An OperationOutcome Resource is returned indicating an issue. Client should contact eHealth Ontario for trouble shooting.

Examples

HealthcareService search request:

POST [base]/HealthcareService?identifier=[system]|[value]


HealthcareService search response:

Examples of a HealthcareService search response can be found below