Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

$check-services Implementation Guidance

$check-services implementation guidance

Check Services Interaction

This is a FHIR Operation performed by an EMS and defined at the server level. The $check-services operation is performed at the end of a triage journey with a generic Referral Request defined in order to find a specific set of nearby services which can meet the needs of the patient in the ReferralRequest.

The $check-services operation in the context of the CDS API Implementation Guide is modelled as UEC-CheckServices-Operation-1.

Request Headers

The following HTTP request headers are supported for this interaction:

Header Value Conformance
Accept The Accept header indicates the format of the response the client is able to understand, this will be one of the following application/fhir+json or application/fhir+xml. See the RESTful API Content types section. MAY
Authorization The Authorization header MUST carry a base64url encoded JSON web token. See the RESTful API Security section. MAY

POST Operation

The $check-services operation is performed by an HTTP POST command as shown:

Parameters

The $check-services operation has a number of parameters. The EMS will select appropriate IN parameters to include in the operation. The Service Directory will return a set of HealthcareService resources.

IN Parameters

Name Cardinality Type FHIR Documentation CDS Implementation Guidance
requestId 0..1 id An optional client-provided identifier to track the request. This SHOULD be populated.
Each invocation of the $check-services method MUST use a unique requestId
The requestId MUST be locally unique
referralRequest 1..1 ReferralRequest The core of the $check-services operation is based on the outcome of triage, represented as a chief concern, next activity and acuity. These are all captured in the ReferralRequest, so this resource contains all that is required for the outcome of triage. This MUST be populated with the Referral Request the EMS received from the CDSS
patient 1..1 Patient The patient for whom the triage took place.
There are a number of patient elements which are used by some of the directories such as age and gender.
This MUST be populated with a CareConnect-Patient
location 1..1 Location The location represents the patient's current location. This MAY be populated
requester 0..1 Practitioner | Patient | RelatedPerson The person initiating the $check-services request This MAY be populated.
The requester is the user of the EMS. This will typically be a Patient or RelatedPerson if the EMS is being used by a member of the public (e.g. a patient-facing public internet system) or a Practitioner where there has been an initiatingOrganisation as part of the triage.
registeredGP 0..1 Organization The organization representing the registered GP of the Patient. This MAY be populated.
Where populated, this MUST be populated with a CareConnect-Organization
Where populated, the Organization MUST specify an odsOrganisationCode identifier.
inputParameters 0..* Parameter The input parameters for a request, if any. These parameters are defined by the target Service Directory. This MAY be populated.
searchDistance 0..* Quantity (Distance | Duration) The distance/duration to search within. This MAY be populated.
May be used to override the default search distance/duration.

OUT Parameters

Name Cardinality Type FHIR Documentation CDS Implementation Guidance
services 1..1 Parameters The output is a Parameters of HealthcareService resources and related information which can deliver the patient's health needs.
parameters 0..* BackboneElement Each healthcare service returned MUST have it's own parameter
name 1..1 string This MUST be populated with the serviceId
part 1..* Parameter Named parts of this parameter. This MUST contain a parameter named service which MUST contain the HealthcareService resource.
This MAY also contain other implementation-specific information about the HealthcareService such as it's distance from the patient's location or capacity.
outputParameters 0..* Parameters The output parameters for a request, if any. These parameters are defined by the target Service Directory.

Response from Service Directory

Success

  • MUST return a 200 OK HTTP status code on successsful execution of the operation.

  • MUST return a Parameters of ‘0’ (zero) or more parts, where each part represents a HealthcareService resource.

  • COULD return a Parameter of output parameters.

Failure

The following errors can be triggered when performing this operation:

Tags: rest fhir api

All content is available under the Open Government Licence v3.0, except where otherwise stated