Healthcare Search
HealthcareService
Profiles & Operations > HealthcareService Search
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
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