Background

This page contains conformance language, capability statements, exchanges, and languages supported.

Conformance Language

This specification uses the conformance verbs SHALL, SHOULD, and MAY as defined in RFC 2119.

1. SHALL: an absolute requirement for all implementations
2. SHALL NOT: an absolute prohibition against inclusion for all implementations
3. SHOULD/SHOULD NOT: A best practice or recommendation to be considered by implementers
4. MAY: This is truly optional language for an implementation; can be included or omitted as the implementer decides with no implications

Capabilities

Exchanging with RESTful API: This implementation MAY follow the Single and Multiple Resource exchange framework. Of the CRUD capabilities, the functionality MAY be used to retrieve context information about HealthcareServices being searched for and received.

Exchanging with Messaging: This implementation SHALL follow synchronous Message Request and Response paradigms. Messages SHALL include only the based FHIR MessageHeader resource, and any resources directly or indirectly referenced from it.

Languages supported: JSON (SHALL) and XML (SHOULD).

Expected Actions

The Care Services Selective Supplier shall retrieve the record indicated by the Resource identifier on the HTTP GET supplied by the Care Services Selective Consumer. The Care Services Selective Supplier shall respond to the retrieve request as described by the following cases:

Case 1: The Care Services Selective Supplier finds the care services record matching the resourceId sent in the HTTP request.

HTTP 200 (OK) is returned as the HTTP status code.

A Care Services Resource is returned representing the result.

Case 2: The Care Services Selective Supplier fails to find the care services record matching the resourceId sent in the HTTP request.

HTTP 404 (Not Found) is returned as the HTTP status code

An OperationOutcome Resource is returned indicating that the Care Services Resource could not be found, in an issue having:

Attribute	Value
Severity	error
Code	not-found

Constraints

MustSupport Definition

The supplier (sender) of the service directory information ​SHALL populate any elements with the MustSupport flag set to true if the information is available and is appropriate to provide​

​The consumer (receiver) of the service directory information​ SHALL be capable of receiving any resource instances containing elements with the MustSupport flag set to true without generating an error or causing the application to fail.​ Elements without a MustSupport flag in a FHIR response SHOULD still be received without generating an error or causing the application to fail.​

Obligations

The CA:CSD provides additional guidance for the implementers through Obligations within a profile that provide coded expectations for what defined actors must support.

• While the Obligation Extension is still new (and evolving), it provides a consistent and potentially machine processable way for profiles to define their expectations for system behaviors.
• Implementors can find the complete list of obligations that have been created for the profiles within their respective JSON at the top of each profile. This information is also made available in the tables below each profile on their respective pages.